diff options
404 files changed, 10081 insertions, 3407 deletions
diff --git a/.gitignore b/.gitignore index d44e72926e..11b7024533 100644 --- a/.gitignore +++ b/.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 diff --git a/README.hardware b/README.hardware index d4f7b47506..f72da94e39 100644 --- a/README.hardware +++ b/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 diff --git a/bitbake/bin/bitbake-runtask b/bitbake/bin/bitbake-runtask index bee0f429ff..394b4c3ef9 100755 --- a/bitbake/bin/bitbake-runtask +++ b/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() - -debug = hashdata["msg-debug"] -debug_domains = hashdata["msg-debug-domains"] -verbose = hashdata["verbose"] +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 + +handler = bb.event.LogHandler() +logger.addHandler(handler) + +#An example to make debug log messages show up +#bb.msg.init_msgconfig(True, 3, []) + +console = logging.StreamHandler(sys.stdout) +format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s") +bb.msg.addDefaultlogFilter(console) +console.setFormatter(format) + +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() -bb.utils.init_logger(bb.msg, verbose, debug, debug_domains) +initialenv = os.environ.copy() +config = BBConfiguration() -cooker = bb.cooker.BBCooker(BBConfiguration(debug, debug_domains), None) -cooker.parseConfiguration() +def register_idle_function(self, function, data): + pass -cooker.bb_cache = bb.cache.init(cooker) -cooker.status = bb.cache.CacheData() +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) = cooker.bb_cache.virtualfn2realfn(buildfile) +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) diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py index 8937f083a1..575ef4aaf1 100644 --- a/bitbake/lib/bb/build.py +++ b/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'): diff --git a/bitbake/lib/bb/codeparser.py b/bitbake/lib/bb/codeparser.py index 83bbb927a0..d425514481 100644 --- a/bitbake/lib/bb/codeparser.py +++ b/bitbake/lib/bb/codeparser.py @@ -150,117 +150,79 @@ def parser_cache_savemerge(d): bb.utils.unlockfile(glf) -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. - """ +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 = [] - 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") +class PythonParser(): + getvars = ("d.getVar", "bb.data.getVar", "data.getVar") + execfuncs = ("bb.build.exec_func", "bb.build.exec_task") - @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 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. + """ - if not strparts: - return True + 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)) - current, rest = strparts[0], strparts[1:] + 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) + + 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) - - 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) + break - 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) - def parse_python(self, node): + 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) diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py index 9537239b03..d65b5ebb31 100644 --- a/bitbake/lib/bb/cooker.py +++ b/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() diff --git a/bitbake/lib/bb/data.py b/bitbake/lib/bb/data.py index ac0d8809cc..7c1533cfa9 100644 --- a/bitbake/lib/bb/data.py +++ b/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 [] diff --git a/bitbake/lib/bb/data_smart.py b/bitbake/lib/bb/data_smart.py index d8ba24ffd7..072f4033a0 100644 --- a/bitbake/lib/bb/data_smart.py +++ b/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 diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py index f6fa46c610..557025f701 100644 --- a/bitbake/lib/bb/fetch2/__init__.py +++ b/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) diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py index fb6125ce3f..56fda9a48c 100644 --- a/bitbake/lib/bb/fetch2/git.py +++ b/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 != "": diff --git a/bitbake/lib/bb/fetch2/local.py b/bitbake/lib/bb/fetch2/local.py index 2bf92c96a5..a0ed4442fb 100644 --- a/bitbake/lib/bb/fetch2/local.py +++ b/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 diff --git a/bitbake/lib/bb/parse/parse_py/BBHandler.py b/bitbake/lib/bb/parse/parse_py/BBHandler.py index c59b468e0b..e2615c6dec 100644 --- a/bitbake/lib/bb/parse/parse_py/BBHandler.py +++ b/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) diff --git a/bitbake/lib/bb/parse/parse_py/ConfHandler.py b/bitbake/lib/bb/parse/parse_py/ConfHandler.py index 102c0e93db..e168d24b4c 100644 --- a/bitbake/lib/bb/parse/parse_py/ConfHandler.py +++ b/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) diff --git a/bitbake/lib/bb/persist_data.py b/bitbake/lib/bb/persist_data.py index 551b58a2a9..4a4505c89b 100644 --- a/bitbake/lib/bb/persist_data.py +++ b/bitbake/lib/bb/persist_data.py @@ -47,9 +47,10 @@ if hasattr(sqlite3, 'enable_shared_cache'): @total_ordering class SQLTable(collections.MutableMapping): """Object representing a table/domain in the database""" - def __init__(self, cursor, table): - self.cursor = cursor + def __init__(self, cachefile, table): + self.cachefile = cachefile self.table = table + self.cursor = connect(self.cachefile) self._execute("CREATE TABLE IF NOT EXISTS %s(key TEXT, value TEXT);" % table) @@ -63,6 +64,8 @@ class SQLTable(collections.MutableMapping): except sqlite3.OperationalError as exc: if 'database is locked' in str(exc) and count < 500: count = count + 1 + self.cursor.close() + self.cursor = connect(self.cachefile) continue raise @@ -188,7 +191,7 @@ class PersistData(object): del self.data[domain][key] def connect(database): - return sqlite3.connect(database, timeout=30, isolation_level=None) + return sqlite3.connect(database, timeout=5, isolation_level=None) def persist(domain, d): """Convenience factory for SQLTable objects based upon metadata""" @@ -201,5 +204,4 @@ def persist(domain, d): bb.utils.mkdirhier(cachedir) cachefile = os.path.join(cachedir, "bb_persist_data.sqlite3") - connection = connect(cachefile) - return SQLTable(connection, domain) + return SQLTable(cachefile, domain) diff --git a/bitbake/lib/bb/runqueue.py b/bitbake/lib/bb/runqueue.py index aca06b57be..30c152e040 100644 --- a/bitbake/lib/bb/runqueue.py +++ b/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)) @@ -1412,18 +1421,20 @@ class RunQueueExecuteScenequeue(RunQueueExecute): sq_revdeps.append(copy.copy(self.rqdata.runq_revdeps[task])) sq_revdeps_new.append(set()) if (len(self.rqdata.runq_revdeps[task]) == 0) and task not in self.rqdata.runq_setscene: - endpoints[task] = None + endpoints[task] = set() for task in self.rqdata.runq_setscene: for dep in self.rqdata.runq_depends[task]: - endpoints[dep] = task + if dep not in endpoints: + endpoints[dep] = set() + endpoints[dep].add(task) def process_endpoints(endpoints): newendpoints = {} for point, task in endpoints.items(): tasks = set() if task: - tasks.add(task) + tasks |= task if sq_revdeps_new[point]: tasks |= sq_revdeps_new[point] sq_revdeps_new[point] = set() @@ -1448,6 +1459,28 @@ class RunQueueExecuteScenequeue(RunQueueExecute): elif len(sq_revdeps_new[task]) != 0: bb.msg.fatal("RunQueue", "Something went badly wrong during scenequeue generation, aborting. Please report this problem.") + # Resolve setscene inter-task dependencies + # e.g. do_sometask_setscene[depends] = "targetname:do_someothertask_setscene" + # Note that anything explicitly depended upon will have its reverse dependencies removed to avoid circular dependencies + for task in self.rqdata.runq_setscene: + realid = self.rqdata.taskData.gettask_id(self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]], self.rqdata.runq_task[task] + "_setscene", False) + idepends = self.rqdata.taskData.tasks_idepends[realid] + for (depid, idependtask) in idepends: + if depid not in self.rqdata.taskData.build_targets: + continue + + depdata = self.rqdata.taskData.build_targets[depid][0] + if depdata is None: + continue + dep = self.rqdata.taskData.fn_index[depdata] + taskid = self.rqdata.get_task_id(self.rqdata.taskData.getfn_id(dep), idependtask.replace("_setscene", "")) + if taskid is None: + bb.msg.fatal("RunQueue", "Task %s depends upon nonexistant task %s:%s" % (self.rqdata.taskData.tasks_name[realid], dep, idependtask)) + + sq_revdeps_squash[self.rqdata.runq_setscene.index(task)].add(self.rqdata.runq_setscene.index(taskid)) + # Have to zero this to avoid circular dependencies + sq_revdeps_squash[self.rqdata.runq_setscene.index(taskid)] = set() + #for task in xrange(len(sq_revdeps_squash)): # print "Task %s: %s.%s is %s " % (task, self.taskData.fn_index[self.runq_fnid[self.runq_setscene[task]]], self.runq_task[self.runq_setscene[task]] + "_setscene", sq_revdeps_squash[task]) @@ -1506,8 +1539,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 +1614,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 +1656,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 diff --git a/bitbake/lib/bb/siggen.py b/bitbake/lib/bb/siggen.py index 12257914cd..d4064c386a 100644 --- a/bitbake/lib/bb/siggen.py +++ b/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")) diff --git a/bitbake/lib/bb/ui/crumbs/hobprefs.py b/bitbake/lib/bb/ui/crumbs/hobprefs.py index 5dfb0e68ce..3f6f128808 100644 --- a/bitbake/lib/bb/ui/crumbs/hobprefs.py +++ b/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() diff --git a/bitbake/lib/bb/ui/crumbs/runningbuild.py b/bitbake/lib/bb/ui/crumbs/runningbuild.py index 509590af35..4f609fc622 100644 --- a/bitbake/lib/bb/ui/crumbs/runningbuild.py +++ b/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)] diff --git a/bitbake/lib/bb/ui/hob.py b/bitbake/lib/bb/ui/hob.py index 71ea88acd7..0fcaad54a7 100644 --- a/bitbake/lib/bb/ui/hob.py +++ b/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 diff --git a/bitbake/lib/bb/utils.py b/bitbake/lib/bb/utils.py index 1f5540716a..521a0683fc 100644 --- a/bitbake/lib/bb/utils.py +++ b/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(): diff --git a/documentation/Makefile b/documentation/Makefile index 21ffc50f37..7cf1c6727e 100644 --- a/documentation/Makefile +++ b/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 diff --git a/documentation/adt-manual/adt-command.xml b/documentation/adt-manual/adt-command.xml index a4197075e1..43bd08b74f 100644 --- a/documentation/adt-manual/adt-command.xml +++ b/documentation/adt-manual/adt-command.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='using-the-command-line'> <title>Using the Command Line</title> @@ -12,9 +13,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 diff --git a/documentation/adt-manual/adt-eclipse.xml b/documentation/adt-manual/adt-eclipse.xml index c1b241c567..2123198064 100644 --- a/documentation/adt-manual/adt-eclipse.xml +++ b/documentation/adt-manual/adt-eclipse.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='adt-eclipse'> <title>Working Within Eclipse</title> @@ -34,6 +35,11 @@ <listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem> <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem> </orderedlist> + <note> + Do not install Eclipse from your distribution's package repository. + Be sure to install Eclipse from the official Eclipse download site as directed + in the next section. + </note> </para> <section id='installing-eclipse-ide'> @@ -43,7 +49,7 @@ It is recommended that you have the Indigo 3.7 version of the Eclipse IDE installed on your development system. If you don’t have this version, you can find it at - <ulink url='http://www.eclipse.org/downloads'></ulink>. + <ulink url='&ECLIPSE_MAIN_URL;'></ulink>. From that site, choose the Eclipse Classic version particular to your development host. This version contains the Eclipse Platform, the Java Development @@ -53,10 +59,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> @@ -98,20 +106,22 @@ <listitem><para>Make sure you are in your Workbench and select "Install New Software" from the "Help" pull-down menu. </para></listitem> - <listitem><para>Select <filename>indigo - http://download.eclipse.org/releases/indigo</filename> + <listitem><para>Select <filename>indigo - &ECLIPSE_INDIGO_URL;</filename> from the "Work with:" pull-down menu.</para></listitem> <listitem><para>Expand the box next to <filename>Programming Languages</filename> and select the <filename>Autotools Support for CDT (incubation)</filename> and <filename>C/C++ Development Tools</filename> boxes.</para></listitem> + <listitem><para>Expand the box next to "Linux Tools" and select the + "LTTng - Linux Tracing Toolkit(incubation)" boxes.</para></listitem> <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem> <listitem><para>After the Eclipse IDE restarts and from the Workbench, select "Install New Software" from the "Help" pull-down menu.</para></listitem> <listitem><para>Click the "Available Software Sites" link.</para></listitem> <listitem><para>Check the box next to - <filename>http://download.eclipse.org/tm/updates/3.3</filename> + <filename>&ECLIPSE_UPDATES_URL;</filename> and click "OK".</para></listitem> - <listitem><para>Select <filename>http://download.eclipse.org/tm/updates/3.3</filename> + <listitem><para>Select <filename>&ECLIPSE_UPDATES_URL;</filename> from the "Work with:" pull-down menu.</para></listitem> <listitem><para>Check the box next to <filename>TM and RSE Main Features</filename>. </para></listitem> @@ -125,7 +135,7 @@ <listitem><para>After clicking "Available Software Sites", check the box next to <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename> and click "OK".</para></listitem> - <listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename> + <listitem><para>Select <filename>&ECLIPSE_INDIGO_CDT_URL;</filename> from the "Work with:" pull-down menu.</para></listitem> <listitem><para>Check the box next to <filename>CDT Main Features</filename>. </para></listitem> @@ -138,30 +148,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>&ECLIPSE_DL_PLUGIN_URL;</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 +185,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 +212,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>&DISTRO;</filename> release: <literallayout class='monospaced'> - $ scripts/build.sh master 1.1M4 + $ scripts/build.sh master &DISTRO; </literallayout> After running the script, the file <filename>org.yocto.sdk-<release>-<date>-archive.zip</filename> @@ -247,22 +225,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 +330,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>&YOCTO_ADTPATH_DIR;</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 +362,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='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section + of The Yocto Project Quick Start for more information.</para></listitem> </itemizedlist> </para> </section> @@ -467,7 +479,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 +504,7 @@ <listitem><para>Expose the <filename>Run -> 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 +523,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 -> Debug Configurations...</filename></para></listitem> @@ -550,7 +564,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 -> YoctoTools</filename> menu. + <filename>YoctoTools</filename> menu. </para> <para> @@ -575,14 +589,14 @@ host can use, you must have <filename>oprofile</filename> version 0.9.4 or greater installed on the host.</para> <para>You can locate both the viewer and server from - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/oprofileui/'></ulink>. + <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>. <note>The <filename>oprofile-server</filename> is installed by default on the <filename>core-image-sato-sdk</filename> image.</note></para></listitem> - <listitem><para><emphasis><filename>Lttng-ust</filename>:</emphasis> Selecting this tool runs - <filename>usttrace</filename> on the remote target, transfers the output data back to the - local host machine, and uses <filename>lttv-gui</filename> to graphically display the output. - The <filename>lttv-gui</filename> must be installed on the local host machine to use this tool. - For information on how to use <filename>lttng</filename> to trace an application, see + <listitem><para><emphasis><filename>Lttng-ust</filename>:</emphasis> Selecting this tool runs + <filename>usttrace</filename> on the remote target, transfers the output data back + to the local host machine, and uses the <filename>lttng</filename> Eclipse plug-in to + graphically display the output. + For information on how to use <filename>lttng</filename> to trace an application, see <ulink url='http://lttng.org/files/ust/manual/ust.html'></ulink>.</para> <para>For <filename>Application</filename>, you must supply the absolute path name of the application to be traced by user mode <filename>lttng</filename>. @@ -590,7 +604,32 @@ <filename>usttrace /path/to/foo</filename> on the remote target to trace the program <filename>/path/to/foo</filename>.</para> <para><filename>Argument</filename> is passed to <filename>usttrace</filename> - running on the remote target.</para></listitem> + running on the remote target.</para> + <para>Before you use the <filename>lttng-ust</filename> tool, you need to setup + the <filename>lttng</filename> Eclipse plug-in and create a <filename>lttng</filename> + project. + Do the following: + <orderedlist> + <listitem><para>Follow these + <ulink url='http://wiki.eclipse.org/Linux_Tools_Project/LTTng#Downloading_and_installing_the_LTTng_parser_library'>instructions</ulink> + to download and install the <filename>lttng</filename> parser library. + </para></listitem> + <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename> + and then select <filename>LTTng</filename>.</para></listitem> + <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective + into the <filename>LTTng</filename> perspective.</para></listitem> + <listitem><para>Create a new <filename>LTTng</filename> project by selecting + <filename>File -> New -> Project</filename>.</para></listitem> + <listitem><para>Choose <filename>LTTng -> LTTng Project</filename>.</para></listitem> + <listitem><para>Click <filename>YoctoTools -> lttng-ust</filename> to start user mode + <filename>lttng</filename> on the remote target.</para></listitem> + </orderedlist></para> + <para>After the output data has been transferred from the remote target back to the local + host machine, new traces will be imported into the selected <filename>LTTng</filename> project. + Then you can go to the <filename>LTTng</filename> project, right click the imported + trace, and set the trace type as the <filename>LTTng</filename> kernel trace. + Finally, right click the imported trace and select <filename>Open</filename> + to display the data graphically.</para></listitem> <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis> Selecting this tool runs <filename>powertop</filename> on the remote target machine and displays the results in a new view called <filename>powertop</filename>.</para> diff --git a/documentation/adt-manual/adt-intro.xml b/documentation/adt-manual/adt-intro.xml index 211b174dc6..44a313284c 100644 --- a/documentation/adt-manual/adt-intro.xml +++ b/documentation/adt-manual/adt-intro.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='adt-intro'> @@ -106,7 +107,7 @@ <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what software is using the most power. You can find out more about PowerTOP at - <ulink url='http://www.linuxpowertop.org/'></ulink>.</para></listitem> + <ulink url='https://01.org/powertop/'></ulink>.</para></listitem> <listitem><para><emphasis>OProfile:</emphasis> A system-wide profiler for Linux systems that is capable of profiling all running code at low overhead. You can find out more about OProfile at @@ -114,7 +115,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. diff --git a/documentation/adt-manual/adt-manual.xml b/documentation/adt-manual/adt-manual.xml index e6f3116b3a..4afe534b04 100644 --- a/documentation/adt-manual/adt-manual.xml +++ b/documentation/adt-manual/adt-manual.xml @@ -1,5 +1,6 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <book id='adt-manual' lang='en' xmlns:xi="http://www.w3.org/2003/XInclude" @@ -43,10 +44,20 @@ <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> + <revision> + <revnumber>1.1.2</revnumber> + <date>July 2012</date> + <revremark>Released with the Yocto Project 1.1.2 Release.</revremark> + </revision> </revhistory> <copyright> - <year>2010-2011</year> + <year>©RIGHT_YEAR;</year> <holder>Linux Foundation</holder> </copyright> @@ -58,9 +69,9 @@ <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='&YOCTO_DOCS_ADT_URL;'> Application Developer's Toolkit (ADT) User's Guide</ulink> on - the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website. + the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. For the latest version of this manual, see the manual on the website. </note> diff --git a/documentation/adt-manual/adt-package.xml b/documentation/adt-manual/adt-package.xml index c035c2d011..26b5dc18d8 100644 --- a/documentation/adt-manual/adt-package.xml +++ b/documentation/adt-manual/adt-package.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='adt-package'> <title>Optionally Customizing the Development Packages Installation</title> @@ -54,9 +55,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='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in The Yocto Project Reference Manual. </note> <para> diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml index 3fa59ec19e..b721ebac4e 100644 --- a/documentation/adt-manual/adt-prepare.xml +++ b/documentation/adt-manual/adt-prepare.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='adt-prepare'> @@ -55,8 +56,10 @@ <para> The ADT Installer is contained in the ADT Installer tarball. - You can download the tarball into any directory from - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/adt_installer'></ulink>. + You can download the tarball into any directory from the + <ulink url='&YOCTO_DL_URL;/releases'>Index of Releases</ulink>, specifically + at + <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink>. Or, you can use BitBake to generate the tarball inside the existing Yocto Project build tree. </para> @@ -79,9 +82,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 &YOCTO_RELEASE_DL_URL;/&YOCTO_POKY_TARBALL; + $ tar xjf &YOCTO_POKY_TARBALL; + $ source &OE_INIT_PATH; $ bitbake adt-installer </literallayout> </para> @@ -93,6 +96,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 ~/poky/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,19 +166,20 @@ <para> After you have configured the <filename>adt_installer.conf</filename> file, - run the installer using the following command: + run the installer using the following command. + Be sure that you are not trying to use cross-compilation tools. + When you run the installer, the environment must use a + host <filename>gcc</filename>: <literallayout class='monospaced'> - $ 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>" - section of - <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'> - The Yocto Project Quick Start</ulink>, then you will have libtool installed. + If you install the recommended packages as described in + "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" + section of The Yocto Project Quick Start, then you will have libtool installed. </note> <para> @@ -181,7 +193,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>&YOCTO_ADTPATH_DIR;</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_<arch></filename> variable @@ -204,17 +216,17 @@ Follow these steps: <orderedlist> <listitem><para>Go to - <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/toolchain'></ulink> + <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink> and find the folder that matches your host development system - (i.e. <filename>i586</filename> for 32-bit machines or - <filename>x86_64</filename> for 64-bit machines).</para></listitem> + (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. For example, if your host development system is an Intel-based 64-bit system and 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-gmae-&DISTRO;.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,7 +243,7 @@ </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>&YOCTO_ADTPATH_DIR;</filename>. Once the tarball is expanded, the cross-toolchain is installed. You will notice environment setup files for the cross-toolchain in the directory. </para></listitem> @@ -294,7 +306,7 @@ 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>&YOCTO_ADTPATH_DIR;</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. @@ -308,7 +320,7 @@ For example, the toolchain environment setup script for a 64-bit IA-based architecture would be the following: <literallayout class='monospaced'> - /opt/poky/1.1/environment-setup-x86_64-poky-linux + &YOCTO_ADTPATH_DIR;/environment-setup-x86_64-poky-linux </literallayout> </para> </section> @@ -330,10 +342,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='&YOCTO_DOCS_QS_URL;#test-run'>A Quick Test Run</ulink>" section of + The Yocto Project Quick Start. </para> <para> @@ -342,12 +352,11 @@ <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='&YOCTO_MACHINES_DL_URL;'></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='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" appendix in + The Yocto Project Reference Manual. </para> <para> @@ -363,7 +372,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. @@ -378,11 +387,11 @@ <listitem><para>Set up the cross-development environment as described in the "<link linkend='setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</link>" section.</para></listitem> - <listitem><para>Get the <filename>tcf-agent</filename> source code, which is - stored using the Subversion SCM, using the following command: + <listitem><para>Get the <filename>tcf-agent</filename> source code using + the following commands: <literallayout class='monospaced'> - $ svn checkout svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent \ - <-r #rev_number> + $ git clone http://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git + $ cd agent </literallayout></para></listitem> <listitem><para>Modify the <filename>Makefile.inc</filename> file for the cross-compilation environment by setting the @@ -422,13 +431,13 @@ filesystem image. For example, the following commands set up the environment and then extract 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 diff --git a/documentation/adt-manual/style.css b/documentation/adt-manual/style.css index 7c24fe5d2d..e75ebc65c3 100644 --- a/documentation/adt-manual/style.css +++ b/documentation/adt-manual/style.css @@ -654,7 +654,7 @@ hr { .tip, .warning, .caution, .note { - border-color: #aaa; + border-color: #fff; } @@ -662,24 +662,24 @@ hr { .warning table th, .caution table th, .note table th { - border-bottom-color: #aaa; + border-bottom-color: #fff; } .warning { - background-color: #fea; + background-color: #f0f0f2; } .caution { - background-color: #fea; + background-color: #f0f0f2; } .tip { - background-color: #eff; + background-color: #f0f0f2; } .note { - background-color: #dfc; + background-color: #f0f0f2; } .glossary dl dt, @@ -946,8 +946,8 @@ table { .tip, .note { - background: #666666; - color: #fff; + background: #f0f0f2; + color: #333; padding: 20px; margin: 20px; } @@ -958,11 +958,26 @@ table { margin: 0em; font-size: 2em; font-weight: bold; - color: #fff; + color: #333; } .tip a, .note a { - color: #fff; + color: #333; text-decoration: underline; } + +.footnote { + font-size: small; + color: #333; +} + +/* Changes the announcement text */ +.tip h3, +.warning h3, +.caution h3, +.note h3 { + font-size:large; + color: #00557D; +} + diff --git a/documentation/bsp-guide/bsp-guide.xml b/documentation/bsp-guide/bsp-guide.xml index 7f06df7110..c62b87f460 100644 --- a/documentation/bsp-guide/bsp-guide.xml +++ b/documentation/bsp-guide/bsp-guide.xml @@ -1,5 +1,6 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <book id='bsp-guide' lang='en' xmlns:xi="http://www.w3.org/2003/XInclude" @@ -55,10 +56,20 @@ <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> + <revision> + <revnumber>1.1.2</revnumber> + <date>July 2012</date> + <revremark>Released with the Yocto Project 1.1.2 Release.</revremark> + </revision> </revhistory> <copyright> - <year>2010-2011</year> + <year>©RIGHT_YEAR;</year> <holder>Linux Foundation</holder> </copyright> @@ -70,9 +81,9 @@ <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='&YOCTO_DOCS_BSP_URL;'> Board Support Package (BSP) Developer's Guide</ulink> on - the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website. + the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. For the latest version of this manual, see the manual on the website. </note> </legalnotice> diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index a1ae8c34a8..4925790458 100644 --- a/documentation/bsp-guide/bsp.xml +++ b/documentation/bsp-guide/bsp.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='bsp'> @@ -18,77 +19,36 @@ </para> <para> - This section (or document if you are reading the BSP Developer's Guide) defines - a structure for these components - so that BSPs follow a commonly understood layout. - Providing a common form allows end-users to understand and become familiar - with the layout. - A common form also encourages standardization - of software support of hardware. + This chapter (or document if you are reading the BSP Developer's Guide) + talks about BSP Layers, defines a structure for components + so that BSPs follow a commonly understood layout, discusses how to customize + a recipe for a BSP, addresses BSP licensing, and provides information that + shows you how to create and manage a + <link linkend='bsp-layers'>BSP Layer</link> using two Yocto Project + <link linkend='using-the-yocto-projects-bsp-tools'>BSP Tools</link>. </para> - <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'> - BSP Development Example</ulink> in - <ulink url='http://www.yoctoproject.org/docs/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'> - wiki page</ulink>. - </note> - - <para> - The proposed format does have elements that are specific to the Yocto Project and - OpenEmbedded build systems. - It is intended that this information can be - used by other systems besides Yocto Project and OpenEmbedded and that it will be simple - to extract information and convert it to other formats if required. - Yocto Project, through its standard layers mechanism, can directly accept the format - described as a layer. - The BSP captures all - the hardware-specific details in one place in a standard format, which is - useful for any person wishing to use the hardware platform regardless of - the build system they are using. - </para> - - <para> - The BSP specification does not include a build system or other tools - - it is concerned with the hardware-specific components only. - At the end - distribution point you can ship the BSP combined with a build system - and other tools. - However, it is important to maintain the distinction that these - are separate components that happen to be combined in certain end products. - </para> - - <section id="bsp-filelayout"> - <title>Example Filesystem Layout</title> + <section id='bsp-layers'> + <title>BSP Layers</title> <para> - The BSP consists of a file structure inside a base directory, which uses the following - naming convention: + The BSP consists of a file structure inside a base directory. + Collectively, you can think of the base directory and the file structure + as a BSP Layer. + BSP Layers use the following naming convention: <literallayout class='monospaced'> meta-<bsp_name> </literallayout> - </para> - - <para> "bsp_name" is a placeholder for the machine or platform name. - Here are some example base directory names: - <literallayout class='monospaced'> - meta-emenlow - meta-n450 - meta-beagleboard - </literallayout> </para> <para> - The base directory (<filename>meta-<bsp_name></filename>) is the root of the BSP layer. - This root is what you add to the <filename>BBLAYERS</filename> - variable in the <filename>build/conf/bblayers.conf</filename> file found in the - Yocto Project file's build directory. + The layer's base directory (<filename>meta-<bsp_name></filename>) is the root + of the BSP Layer. + This root is what you add to the + <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink> + variable in the <filename>conf/bblayers.conf</filename> file found in the + Yocto Project Build Directory. Adding the root allows the Yocto Project build system to recognize the BSP definition and from it build an image. Here is an example: @@ -99,15 +59,78 @@ /usr/local/src/yocto/meta-<bsp_name> \ " </literallayout> + </para> + + <para> + Some BSPs require additional layers on + top of the BSP's root layer in order to be functional. + For these cases, you also need to add those layers to the + <filename>BBLAYERS</filename> variable in order to build the BSP. + You must also specify in the "Dependencies" section of the BSP's + <filename>README</filename> file any requirements for additional + layers and, preferably, any + build instructions that might be contained elsewhere + in the <filename>README</filename> file. + </para> + + <para> + Some layers function as a layer to hold other BSP layers. + An example of this type of layer is the <filename>meta-intel</filename> layer. + The <filename>meta-intel</filename> layer contains over 10 individual BSP layers. + </para> + + <para> 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='&YOCTO_DOCS_REF_URL;#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'> - The Yocto Project Development Manual</ulink>. + <ulink url='&YOCTO_DOCS_DEV_URL;'>The Yocto Project Development Manual</ulink>. + </para> + </section> + + + <section id="bsp-filelayout"> + <title>Example Filesystem Layout</title> + + <para> + Providing a common form allows end-users to understand and become familiar + with the layout. + A common format also encourages standardization of software support of hardware. + </para> + + <para> + The proposed form does have elements that are specific to the Yocto Project and + OpenEmbedded build systems. + It is intended that this information can be + used by other systems besides Yocto Project and OpenEmbedded and that it will be simple + to extract information and convert it to other formats if required. + Yocto Project, through its standard layers mechanism, can directly accept the format + described as a layer. + The BSP captures all + the hardware-specific details in one place in a standard format, which is + useful for any person wishing to use the hardware platform regardless of + the build system they are using. + </para> + + <para> + The BSP specification does not include a build system or other tools - + it is concerned with the hardware-specific components only. + At the end-distribution point, you can ship the BSP combined with a build system + and other tools. + However, it is important to maintain the distinction that these + are separate components that happen to be combined in certain end products. </para> <para> - Below is the common form for the file structure inside a base directory. + Before looking at the common form for the file structure inside a BSP Layer, + you should be aware that some requirements do exist in order for a BSP to + be considered compliant with the Yocto Project. + For that list of requirements, see the + "<link linkend='released-bsp-requirements'>Released BSP Requirements</link>" + section. + </para> + + <para> + Below is the common form for the file structure inside a BSP Layer. While you can use this basic form for the standard, realize that the actual structures for specific BSPs could differ. @@ -115,10 +138,12 @@ meta-<bsp_name>/ meta-<bsp_name>/<bsp_license_file> meta-<bsp_name>/README + meta-<bsp_name>/README.sources meta-<bsp_name>/binary/<bootable_images> meta-<bsp_name>/conf/layer.conf meta-<bsp_name>/conf/machine/*.conf meta-<bsp_name>/recipes-bsp/* + meta-<bsp_name>/recipes-core/* meta-<bsp_name>/recipes-graphics/* meta-<bsp_name>/recipes-kernel/linux/linux-yocto_<kernel_rev>.bbappend </literallayout> @@ -130,7 +155,8 @@ <literallayout class='monospaced'> meta-crownbay/COPYING.MIT meta-crownbay/README - meta-crownbay/binary + meta-crownbay/README.sources + meta-crownbay/binary/ meta-crownbay/conf/ meta-crownbay/conf/layer.conf meta-crownbay/conf/machine/ @@ -149,10 +175,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 @@ -174,7 +197,7 @@ <title>License Files</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find these files in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/<bsp_license_file> </literallayout> @@ -196,7 +219,7 @@ <section id="bsp-filelayout-readme"> <title>README File</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find this file in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/README </literallayout> @@ -204,21 +227,41 @@ <para> This file provides information on how to boot the live images that are optionally - included in the <filename>/binary</filename> directory. + included in the <filename>binary/</filename> directory. The <filename>README</filename> file also provides special information needed for building the image. </para> <para> - Technically speaking a <filename>README</filename> is optional but it is highly - recommended that every BSP has one. + At a minimum, the <filename>README</filename> file must + contain a list of dependencies, such as the names of + any other layers on which the BSP depends and the name of + the BSP maintainer with his or her contact information. + </para> + </section> + + <section id="bsp-filelayout-readme-sources"> + <title>README.sources File</title> + <para> + You can find this file in the BSP Layer at: + <literallayout class='monospaced'> + meta-<bsp_name>/README.sources + </literallayout> + </para> + + <para> + This file provides information on where to locate the BSP source files. + For example, information provides where to find the sources that comprise + the images shipped with the BSP. + Information is also included to help you find the metadata used to generate the images + that ship with the BSP. </para> </section> <section id="bsp-filelayout-binary"> <title>Pre-built User Binaries</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find these files in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/binary/<bootable_images> </literallayout> @@ -228,24 +271,25 @@ This optional area contains useful pre-built kernels and user-space filesystem images appropriate to the target system. This directory typically contains graphical (e.g. sato) and minimal live images - when the BSP tarball has been created and made available in the Yocto Project website. + when the BSP tarball has been created and made available in the + <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. You can use these kernels and images to get a system running and quickly get started on development tasks. </para> <para> The exact types of binaries present are highly hardware-dependent. - However, a README file should be present in the BSP file structure that explains how to use + However, a README file should be present in the BSP Layer that explains how to use the kernels and images with the target hardware. If pre-built binaries are present, source code to meet licensing requirements must also - be provided in some form. + exist in some form. </para> </section> <section id='bsp-filelayout-layer'> <title>Layer Configuration File</title> <para> - You can find this file in the Yocto Project file's directory structure at: + You can find this file in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/conf/layer.conf </literallayout> @@ -256,13 +300,14 @@ Project layer, identifies the contents of the layer, and contains information about how Yocto Project should use it. Generally, a standard boilerplate file such as the following works. - In the following example you would replace "bsp" and "_bsp" with the actual name - of the BSP (i.e. <bsp_name> from the example template). + In the following example, you would replace "<filename>bsp</filename>" and + "<filename>_bsp</filename>" with the actual name + of the BSP (i.e. <filename><bsp_name></filename> from the example template). </para> <para> <literallayout class='monospaced'> - # We have a conf directory, add to BBPATH + # We have a conf and classes directory, add to BBPATH BBPATH := "${BBPATH}:${LAYERDIR}" # We have a recipes directory containing .bb and .bbappend files, add to BBFILES @@ -276,15 +321,25 @@ </para> <para> + To illustrate the string substitutions, here are the last three statements from the Crown + Bay <filename>conf/layer.conf</filename> file: + <literallayout class='monospaced'> + BBFILE_COLLECTIONS += "crownbay" + BBFILE_PATTERN_crownbay := "^${LAYERDIR}/" + BBFILE_PRIORITY_crownbay = "6" + </literallayout> + </para> + + <para> This file simply makes BitBake aware of the recipes and configuration directories. - This file must exist so that the Yocto Project build system can recognize the BSP. + The file must exist so that the Yocto Project build system can recognize the BSP. </para> </section> <section id="bsp-filelayout-machine"> <title>Hardware Configuration Options</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find these files in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/conf/machine/*.conf </literallayout> @@ -296,19 +351,20 @@ If the BSP supports multiple machines, multiple machine configuration files can be present. These filenames correspond to the values to which users have set the - <filename>MACHINE</filename> variable. + <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable. </para> <para> These files define things such as the kernel package to use - (<filename>PREFERRED_PROVIDER</filename> of virtual/kernel), the hardware drivers to + (<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink> + of virtual/kernel), the hardware drivers to include in different types of images, any special software components that are needed, any bootloader information, and also any special image format requirements. </para> <para> - At least one machine file is required for a BSP layer. + Each BSP Layer requires at least one machine file. However, you can supply more than one file. For example, in the Crown Bay BSP shown earlier in this section, the <filename>conf/machine</filename> directory contains two configuration files: @@ -324,7 +380,7 @@ <para> This <filename>crownbay.conf</filename> file could also include a hardware "tuning" file that is commonly used to - define the the package architecture and specify + define the package architecture and specify optimization flags, which are carefully chosen to give best performance on a given processor. </para> @@ -344,7 +400,7 @@ <section id='bsp-filelayout-misc-recipes'> <title>Miscellaneous Recipe Files</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find these files in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/recipes-bsp/* </literallayout> @@ -359,7 +415,10 @@ Furthermore, there are machine-specific settings used during the build that are defined by the <filename>machconfig</filename> files. In the Crown Bay example, two <filename>machconfig</filename> files exist: - one that supports the Intel EMGD and one that does not: + one that supports the + <trademark class='registered'>Intel</trademark> Embedded + Media and Graphics Driver (<trademark class='registered'>Intel</trademark> + EMGD) and one that does not: <literallayout class='monospaced'> meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig @@ -376,14 +435,16 @@ <section id='bsp-filelayout-core-recipes'> <title>Core Recipe Files</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find these files in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/recipes-core/* </literallayout> </para> <para> - This directory contains recipe files for the core. + This directory contains recipe files that are almost always necessary to build a + useful, working Linux image. + Thus, the term "core" is used to group these recipes. For example, in the Crown Bay BSP there is the <filename>task-core-tools.bbappend</filename> file, which is an append file used to recommend that the SystemTap package be included as a package when the image @@ -394,7 +455,7 @@ <section id='bsp-filelayout-recipes-graphics'> <title>Display Support Files</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find these files in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/recipes-graphics/* </literallayout> @@ -404,10 +465,13 @@ This optional directory contains recipes for the BSP if it has special requirements for graphics support. All files that are needed for the BSP to support a display are kept here. - For example, the Crown Bay BSP contains the following files that support - building a BSP that supports and does not support the Intel EMGD: + For example, the Crown Bay BSP contains two versions of the + <filename>xorg.conf</filename> file. + The version in <filename>crownbay</filename> builds a BSP that supports the + <trademark class='registered'>Intel</trademark> Embedded Media Graphics Driver (EMGD), + while the version in <filename>crownbay-noemgd</filename> builds + a BSP that supports Video Electronics Standards Association (VESA) graphics only: <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 @@ -418,7 +482,7 @@ <section id='bsp-filelayout-kernel'> <title>Linux Kernel Configuration</title> <para> - You can find these files in the Yocto Project file's directory structure at: + You can find these files in the BSP Layer at: <literallayout class='monospaced'> meta-<bsp_name>/recipes-kernel/linux/linux-yocto_*.bbappend </literallayout> @@ -431,12 +495,11 @@ For your BSP, you typically want to use an existing Yocto Project kernel found in the Yocto Project repository at <filename>meta/recipes-kernel/linux</filename>. You can append your specific changes to the kernel recipe by using a - similarly named append file, which is located in the - <filename>meta-<bsp_name>/recipes-kernel/linux</filename> - directory. + similarly named append file, which is located in the BSP Layer (e.g. + the <filename>meta-<bsp_name>/recipes-kernel/linux</filename> directory). </para> <para> - Suppose you use a BSP that uses the <filename>linux-yocto_3.0.bb</filename> kernel, + Suppose the BSP uses the <filename>linux-yocto_3.0.bb</filename> kernel, which is the preferred kernel to use for developing a new BSP using the Yocto Project. In other words, you have selected the kernel in your <filename><bsp_name>.conf</filename> file by adding the following statements: @@ -453,7 +516,10 @@ <literallayout class='monospaced'> meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend </literallayout> - The file contains the following: + The following listing shows the file. + Be aware that the actual commit ID strings in this example listing might be different + than the actual strings in the file from the <filename>meta-intel</filename> + Git source repository. <literallayout class='monospaced'> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" @@ -465,14 +531,14 @@ 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. + This append file contains statements used to support the Crown Bay BSP for both + <trademark class='registered'>Intel</trademark> EMGD and the VESA graphics. The build process, in this case, recognizes and uses only the statements that apply to the defined machine name - <filename>crownbay</filename> in this case. So, the applicable statements in the <filename>linux-yocto_3.0.bbappend</filename> @@ -484,8 +550,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 @@ -507,14 +573,14 @@ </para> <para> For example, suppose you had a set of configuration options in a file called - <filename>defconfig</filename>. + <filename>myconfig</filename>. If you put that file inside a directory named <filename>/linux-yocto</filename> and then added a <filename>SRC_URI</filename> statement such as the following to the append file, those configuration options will be picked up and applied when the kernel is built. <literallayout class='monospaced'> - SRC_URI += "file://defconfig" + SRC_URI += "file://myconfig" </literallayout> </para> <para> @@ -524,30 +590,35 @@ into their own files and add those by using a <filename>SRC_URI</filename> statement like the following in your append file: <literallayout class='monospaced'> - SRC_URI += "file://defconfig \ + SRC_URI += "file://myconfig \ file://eth.cfg \ file://gfx.cfg" </literallayout> </para> <para> - The <filename>FILESEXTRAPATHS</filename> variable is in boilerplate form here - in order to make it easy to do that. - It basically allows those configuration files to be found by the build process. + The <filename>FILESEXTRAPATHS</filename> variable is in boilerplate form in the + previous example in order to make it easy to do that. + This variable must be in your layer or BitBake will not find the patches or + configurations even if you have them in your <filename>SRC_URI</filename>. + The <filename>FILESEXTRAPATHS</filename> variable enables the build process to + find those configuration files. </para> <note> <para> Other methods exist to accomplish grouping and defining configuration options. - For example, you could directly add configuration options to the Yocto kernel + For example, if you are working with a local clone of the kernel repository, + you could checkout the kernel's <filename>meta</filename> branch, make your changes, + and then push the changes to the local bare clone of the kernel. + The result is that you directly add configuration options to the Yocto kernel <filename>meta</filename> branch for your BSP. 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'> - The Yocto Project Kernel Architecture and Use Manual</ulink>.</para> + <ulink url='&YOCTO_DOCS_KERNEL_URL;'>The Yocto Project Kernel Architecture and Use Manual</ulink>.</para> <para> In general, however, the Yocto Project maintainers take care of moving the <filename>SRC_URI</filename>-specified - configuration options to the <filename>meta</filename> branch. + configuration options to the kernel's <filename>meta</filename> branch. Not only is it easier for BSP developers to not have to worry about putting those configurations in the branch, but having the maintainers do it allows them to apply 'global' knowledge about the kinds of common configuration options multiple BSPs in @@ -557,136 +628,811 @@ </section> </section> - <section id='bsp-click-through-licensing'> - <title>BSP 'Click-Through' Licensing Procedure</title> + <section id='requirements-and-recommendations-for-released-bsps'> + <title>Requirements and Recommendations for Released BSPs</title> - <note> This section describes how - click-through licensing is expected to work. - Currently, this functionality is not yet implemented. - </note> + <para> + Certain requirements exist for a released BSP to be considered + compliant with the Yocto Project. + Additionally, a single recommendation also exists. + This section describes the requirements and recommendation for + released BSPs. + </para> + + <section id='released-bsp-requirements'> + <title>Released BSP Requirements</title> + + <para> + Before looking at BSP requirements, you should consider the following: + <itemizedlist> + <listitem><para>The requirements here assume the BSP layer is a well-formed, "legal" + layer that can be added to the Yocto Project. + For guidelines on creating a Yocto Project layer that meets these base requirements, see the + "<link linkend='bsp-layers'>BSP Layers</link>" section.</para></listitem> + <listitem><para>The requirements in this section apply regardless of how you + ultimately package a BSP. + You should consult the packaging and distribution guidelines for your + specific release process. + For an example of packaging and distribution requirements, see the + <ulink url='&YOCTO_WIKI_URL;/wiki/Third_Party_BSP_Release_Process'>Third + Party BSP Release Process</ulink> wiki page.</para></listitem> + <listitem><para>The requirements for the BSP as it is made available to a developer + are completely independent of the released form of the BSP. + For example, the BSP metadata can be contained within a Git repository + and could have a directory structure completely different from what appears + in the officially released BSP layer.</para></listitem> + <listitem><para>It is not required that specific packages or package + modifications exist in the BSP layer, beyond the requirements for general + compliance with the Yocto Project. + For example, no requirement exists dictating that a specific kernel or + kernel version be used in a given BSP.</para></listitem> + </itemizedlist> + </para> + + <para> + Following are the requirements for a released BSP that conforms to the + Yocto Project: + <itemizedlist> + <listitem><para><emphasis>Layer Name:</emphasis> + The BSP must have a layer name that follows the Yocto + Project standards. + For information on BSP layer names, see the + "<link linkend='bsp-layers'>BSP Layers</link>" section. + </para></listitem> + <listitem><para><emphasis>File System Layout:</emphasis> + When possible, use the same directory names in your + BSP layer as listed in the <filename>recipes.txt</filename> file. + In particular, you should place recipes + (<filename>.bb</filename> files) and recipe + modifications (<filename>.bbappend</filename> files) into + <filename>recipes-*</filename> subdirectories by functional area + as outlined in <filename>recipes.txt</filename>. + If you cannot find a category in <filename>recipes.txt</filename> + to fit a particular recipe, you can make up your own + <filename>recipe-*</filename> subdirectory. + You can find <filename>recipes.txt</filename> in the + <filename>meta</filename> directory of the + Yocto Project Files, or in the OpenEmbedded Core Layer + (<filename>openembedded-core</filename>) found at + <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>. + </para> + <para>Within any particular <filename>recipes-*</filename> category, the layout + should match what is found in the OpenEmbedded Core + Git repository (<filename>openembedded-core</filename>) + or the Yocto Project Files (<filename>poky</filename>). + In other words, make sure you place related files in appropriately + related <filename>recipes-*</filename> subdirectories specific to the + recipe's function, or within a subdirectory containing a set of closely-related + recipes. + The recipes themselves should follow the general guidelines + for recipes used in the Yocto Project found in the + <ulink url='https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide'>Yocto + Recipe and Patch Style Guide</ulink>.</para></listitem> + <listitem><para><emphasis>License File:</emphasis> + You must include a license file in the + <filename>meta-<bsp_name></filename> directory. + This license covers the BSP metadata as a whole. + You must specify which license to use since there is no + default license if one is not specified. + See the + <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/COPYING.MIT'><filename>COPYING.MIT</filename></ulink> + file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer + as an example.</para></listitem> + <listitem><para><emphasis>README File:</emphasis> + You must include a <filename>README</filename> file in the + <filename>meta-<bsp_name></filename> directory. + See the + <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README'><filename>README</filename></ulink> + file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer + as an example.</para> + <para>At a minimum, the <filename>README</filename> file should + contain the following: + <itemizedlist> + <listitem><para>A brief description about the hardware the BSP + targets.</para></listitem> + <listitem><para>A list of all the dependencies a + on which a BSP layer depends. + These dependencies are typically a list of required layers needed + to build the BSP. + However, the dependencies should also contain information regarding + any other dependencies the BSP might have.</para></listitem> + <listitem><para>Any required special licensing information. + For example, this information includes information on + special variables needed to satisfy a EULA, + or instructions on information needed to build or distribute + binaries built from the BSP metadata.</para></listitem> + <listitem><para>The name and contact information for the + BSP layer maintainer. + This is the person to whom patches and questions should + be sent.</para></listitem> + <listitem><para>Instructions on how to build the BSP using the BSP + layer.</para></listitem> + <listitem><para>Instructions on how to boot the BSP build from + the BSP layer.</para></listitem> + <listitem><para>Instructions on how to boot the binary images + contained in the <filename>/binary</filename> directory, + if present.</para></listitem> + <listitem><para>Information on any known bugs or issues that users + should know about when either building or booting the BSP + binaries.</para></listitem> + </itemizedlist></para></listitem> + <listitem><para><emphasis>README.sources File:</emphasis> + You must include a <filename>README.sources</filename> in the + <filename>meta-<bsp_name></filename> directory. + This file specifies exactly where you can find the sources used to + generate the binary images contained in the + <filename>/binary</filename> directory, if present. + See the + <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README.sources'><filename>README.sources</filename></ulink> + file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer + as an example.</para></listitem> + <listitem><para><emphasis>Layer Configuration File:</emphasis> + You must include a <filename>conf/layer.conf</filename> in the + <filename>meta-<bsp_name></filename> directory. + This file identifies the <filename>meta-<bsp_name></filename> + BSP layer as a layer to the build system.</para></listitem> + <listitem><para><emphasis>Machine Configuration File:</emphasis> + You must include a <filename>conf/machine/<bsp_name>.conf</filename> + in the <filename>meta-<bsp_name></filename> directory. + This configuration file defines a machine target that can be built + using the BSP layer. + Multiple machine configuration files define variations of machine + configurations that are supported by the BSP. + If a BSP supports more multiple machine variations, you need to + adequately describe each variation in the BSP + <filename>README</filename> file. + Do not use multiple machine configuration files to describe disparate + hardware. + Multiple machine configuration files should describe very similar targets. + If you do have very different targets, you should create a separate + BSP. + <note>It is completely possible for a developer to structure the + working repository as a conglomeration of unrelated BSP + files, and to possibly generate specifically targeted 'release' BSPs + from that directory using scripts or some other mechanism. + Such considerations are outside the scope of this document.</note> + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='released-bsp-recommendations'> + <title>Released BSP Recommendations</title> + + <para> + Following are recommendations for a released BSP that conforms to the + Yocto Project: + <itemizedlist> + <listitem><para><emphasis>Bootable Images:</emphasis> + BSP releases + can contain one or more bootable images. + Including bootable images allows users to easily try out the BSP + on their own hardware.</para> + <para>In some cases, it might not be convenient to include a + bootable image. + In this case, you might want to make two versions of the + BSP available: one that contains binary images, and one + that does not. + The version that does not contain bootable images avoids + unnecessary download times for users not interested in the images. + </para> + <para>If you need to distribute a BSP and include bootable images or build kernel and + filesystems meant to allow users to boot the BSP for evaluation + purposes, you should put the images and artifacts within a + <filename>binary/</filename> subdirectory located in the + <filename>meta-<bsp_name></filename> directory. + <note>If you do include a bootable image as part of the BSP and the image + was built by software covered by the GPL or other open source licenses, + it is your responsibility to understand + and meet all licensing requirements, which could include distribution + of source files.</note></para></listitem> + <listitem><para><emphasis>Use a Yocto Linux Kernel:</emphasis> + Kernel recipes in the BSP should be based on a Yocto Linux kernel. + Basing your recipes on these kernels reduces the costs for maintaining + the BSP and increases its scalability. + See the <filename>Yocto Linux Kernel</filename> category in the + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>Yocto Source Repositories</ulink> + for these kernels.</para></listitem> + </itemizedlist> + </para> + </section> + </section> + + <section id='customizing-a-recipe-for-a-bsp'> + <title>Customizing a Recipe for a BSP</title> <para> - In some cases, a BSP contains separately licensed IP - (Intellectual Property) for a component that imposes - upon the user a requirement to accept the terms of a - 'click-through' license. - Once the license is accepted the - Yocto Project build system can then build and include the - corresponding component in the final BSP image. - Some affected components might be essential to the normal - functioning of the system and have no 'free' replacement - (i.e. the resulting system would be non-functional - without them). - On the other hand, other components might be simply - 'good-to-have' or purely elective, or if essential - nonetheless have a 'free' (possibly less-capable) - version that could be used as a in the BSP recipe. + If you plan on customizing a recipe for a particular BSP, you need to do the + following: + <itemizedlist> + <listitem><para>Include within the BSP layer a <filename>.bbappend</filename> + file for the modified recipe.</para></listitem> + <listitem><para>Place the BSP-specific file in the BSP's recipe + <filename>.bbappend</filename> file path under a directory named + after the machine.</para></listitem> + </itemizedlist> + </para> + + <para> + To better understand this, consider an example that customizes a recipe by adding + a BSP-specific configuration file named <filename>interfaces</filename> to the + <filename>netbase_4.47.bb</filename> recipe for machine "xyz". + Do the following: + <orderedlist> + <listitem><para>Edit the <filename>netbase_4.47.bbappend</filename> file so that it + contains the following: + <literallayout class='monospaced'> + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + PRINC := "${@int(PRINC) + 2}" + </literallayout></para></listitem> + <listitem><para>Create and place the new <filename>interfaces</filename> + configuration file in the BSP's layer here: + <literallayout class='monospaced'> + meta-xyz/recipes-core/netbase/files/xyz/interfaces + </literallayout></para></listitem> + </orderedlist> </para> + </section> + + <section id='bsp-licensing-considerations'> + <title>BSP Licensing Considerations</title> <para> - For cases where you can substitute something and still maintain functionality, - the Yocto Project website's - <ulink url='http://www.yoctoproject.org/download/all?keys=&download_type=1&download_version='>BSP Download Page</ulink> - makes available 'de-featured' BSPs that are completely free of any IP encumbrances. - For these cases you can use the substitution directly and without any further licensing - requirements. - If present, these fully 'de-featured' BSPs are named appropriately different - as compared to the names of the respective encumbered BSPs. - If available, these substitutions are the simplest and most preferred options. - This, of course, assumes the resulting functionality meets requirements. + In some cases, a BSP contains separately licensed Intellectual Property (IP) + for a component or components. + For these cases, you are required to accept the terms of a commercial or other + type of license that requires some kind of explicit End User License Agreement (EULA). + Once the license is accepted, the Yocto Project build system can then build and + include the corresponding component in the final BSP image. + If the BSP is available as a pre-built image, you can download the image after + agreeing to the license or EULA. </para> <para> - If however, a non-encumbered version is unavailable or the 'free' version - would provide unsuitable functionality or quality, you can use - an encumbered version. + You could find that some separately licensed components that are essential + for normal operation of the system might not have an unencumbered (or free) + substitute. + Without these essential components, the system would be non-functional. + Then again, you might find that other licensed components that are simply + 'good-to-have' or purely elective do have an unencumbered, free replacement + component that you can use rather than agreeing to the separately licensed component. + Even for components essential to the system, you might find an unencumbered component + that is not identical but will work as a less-capable version of the + licensed version in the BSP recipe. </para> - <para> - Several methods exist within the Yocto Project build system to satisfy the licensing - requirements for an encumbered BSP. - The following list describes them in preferential order: + <para> + For cases where you can substitute a free component and still + maintain the system's functionality, the Yocto Project website's + <ulink url='&YOCTO_HOME_URL;/download/all?keys=&download_type=1&download_version='>BSP + Download Page</ulink> makes available de-featured BSPs + that are completely free of any IP encumbrances. + For these cases, you can use the substitution directly and + without any further licensing requirements. + If present, these fully de-featured BSPs are named appropriately + different as compared to the names of the respective + encumbered BSPs. + If available, these substitutions are your + simplest and most preferred options. + Use of these substitutions of course assumes the resulting functionality meets + system requirements. + </para> + + <para> + If however, a non-encumbered version is unavailable or + it provides unsuitable functionality or quality, you can use an encumbered + version. + </para> + + <para> + A couple different methods exist within the Yocto + Project build system to satisfy the licensing + requirements for an encumbered BSP. + The following list describes them in order of preference: + <orderedlist> + <listitem><para><emphasis>Use the <filename>LICENSE_FLAGS</filename> variable + to define the Yocto Project recipes that have commercial or other types of + specially-licensed packages:</emphasis> + For each of those recipes, you can + specify a matching license string in a + <filename>local.conf</filename> variable named + <filename>LICENSE_FLAGS_WHITELIST</filename>. + Specifying the matching license string signifies that you agree to the license. + Thus, the build system can build the corresponding recipe and include + the component in the image. + See the + "<ulink url='&YOCTO_DOCS_REF_URL;#enabling-commercially-licensed-recipes'>Enabling + Commercially Licensed Recipes</ulink>" section in the Yocto Project Reference + Manual for details on how to use these variables.</para> + <para>If you build as you normally would, without + specifying any recipes in the + <filename>LICENSE_FLAGS_WHITELIST</filename>, the build stops and + provides you with the list of recipes that you have + tried to include in the image that need entries in + the <filename>LICENSE_FLAGS_WHITELIST</filename>. + Once you enter the appropriate license flags into the whitelist, + restart the build to continue where it left off. + During the build, the prompt will not appear again + since you have satisfied the requirement.</para> + <para>Once the appropriate license flags are on the white list + in the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, you + can build the encumbered image with no change at all + to the normal build process.</para></listitem> + <listitem><para><emphasis>Get a pre-built version of the BSP:</emphasis> + You can get this type of BSP by visiting the Yocto Project website's + <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> + page and clicking on "BSP Downloads". + You can download BSP tarballs that contain proprietary components + after agreeing to the licensing + requirements of each of the individually encumbered + packages as part of the download process. + Obtaining the BSP this way allows you to access an encumbered + image immediately after agreeing to the + click-through license agreements presented by the + website. + Note that if you want to build the image + yourself using the recipes contained within the BSP + tarball, you will still need to create an + appropriate <filename>LICENSE_FLAGS_WHITELIST</filename> to match the + encumbered recipes in the BSP.</para></listitem> + </orderedlist> + </para> + + <note> + Pre-compiled images are bundled with + a time-limited kernel that runs for a + predetermined amount of time (10 days) before it forces + the system to reboot. + This limitation is meant to discourage direct redistribution + of the image. + You must eventually rebuild the image if you want to remove this restriction. + </note> + </section> + + <section id='using-the-yocto-projects-bsp-tools'> + <title>Using the Yocto Project's BSP Tools</title> + + <para> + The Yocto Project includes a couple of tools that enable + you to create a <link linkend='bsp-layers'>BSP layer</link> + from scratch and do basic configuration and maintenance + of the kernel without ever looking at a Yocto Project metadata file. + These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>, + respectively. + </para> + + <para> + The following sections describe the common location and help features as well + as details for the <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> + tools. </para> - <orderedlist> - <listitem> + <section id='common-features'> + <title>Common Features</title> - <para> - Get a license key (or keys) for the encumbered BSP by visiting - a website and providing the name of the BSP and your email address - through a web form. + <para> + Designed to have a command interface somewhat like + <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>, each + tool is structured as a set of sub-commands under a + top-level command. + The top-level command (<filename>yocto-bsp</filename> + or <filename>yocto-kernel</filename>) itself does + nothing but invoke or provide help on the sub-commands + it supports. </para> - - <para> - After agreeing to any applicable license terms, the - BSP key(s) will be immediately sent to the address - you gave and you can use them by specifying BSPKEY_<keydomain> - environment variables when building the image: - </para> - - <literallayout class='monospaced'> - $ BSPKEY_<keydomain>=<key> bitbake core-image-sato - </literallayout> - - <para> - These steps allow the encumbered image to be built - with no change at all to the normal build process. - </para> - - <para> - Equivalently and probably more conveniently, a line - for each key can instead be put into the user's - <filename>local.conf</filename> file found in the Yocto Project file's - build directory. - </para> - - <para> - The <keydomain> component of the - BSPKEY_<keydomain> is required because there - might be multiple licenses in effect for a given BSP. - In such cases, a given <keydomain> corresponds to - a particular license. In order for an encumbered - BSP that encompasses multiple key domains to be built - successfully, a <keydomain> entry for each - applicable license must be present in <filename>local.conf</filename> or - supplied on the command-line. - </para> - </listitem> - <listitem> - <para> - Do nothing - build as you normally would. - When a license is needed the build will stop and prompt you with instructions. - Follow the license prompts that originate from the - encumbered BSP. - These prompts usually take the form of instructions - needed to manually fetch the encumbered package(s) - and md5 sums into the required directory - (e.g. the <filename>yocto/build/downloads</filename>). - Once the manual package fetch has been - completed, restart the build to continue where - it left off. - During the build the prompt will not appear again since you have satisfied the - requirement. - </para> - </listitem> - <listitem> - <para> - Get a full-featured BSP recipe rather than a key. - You can do this by visiting the applicable BSP download page from the Yocto - Project website at - <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink>. - BSP tarballs that have proprietary information can be downloaded after agreeing - to licensing requirements as part of the download process. - Obtaining the code this way allows you to build an encumbered image with - no changes at all as compared to the normal build. + + <para> + Both tools reside in the <filename>scripts/</filename> subdirectory + of the Yocto Project Files. + Consequently, to use the scripts, you must <filename>source</filename> the + environment just as you would when invoking a build: + <literallayout class='monospaced'> + $ source oe-init-build-env [build_dir] + </literallayout> </para> - </listitem> - </orderedlist> - <para> - Note that the third method is also the only option available - when downloading pre-compiled images generated from non-free BSPs. - Those images are likewise available at from the Yocto Project website. - </para> - </section> + <para> + The most immediately useful function is to get help on both tools. + The built-in help system makes it easy to drill down at + any time and view the syntax required for any specific command. + Simply enter the name of the command, or the command along with + <filename>help</filename> to display a list of the available sub-commands. + Here is an example: + <literallayout class='monospaced'> + $ yocto-bsp + $ yocto-bsp help + + Usage: + + Create a customized Yocto BSP layer. + + usage: yocto-bsp [--version] [--help] COMMAND [ARGS] + + The most commonly used 'yocto-bsp' commands are: + create Create a new Yocto BSP + list List available values for options and BSP properties + + See 'yocto-bsp help COMMAND' for more information on a specific command. + + + Options: + --version show program's version number and exit + -h, --help show this help message and exit + -D, --debug output debug information + </literallayout> + </para> + + <para> + Similarly, entering just the name of a sub-command shows the detailed usage + for that sub-command: + <literallayout class='monospaced'> + $ yocto-bsp create + + Usage: + + Create a new Yocto BSP + usage: yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] + [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] + + This command creates a Yocto BSP based on the specified parameters. + The new BSP will be a new Yocto BSP layer contained by default within + the top-level directory specified as 'meta-bsp-name'. The -o option + can be used to place the BSP layer in a directory with a different + name and location. + + ... + </literallayout> + </para> + + <para> + For any sub-command, you can also use the word 'help' just before the + sub-command to get more extensive documentation: + <literallayout class='monospaced'> + $ yocto-bsp help create + + NAME + yocto-bsp create - Create a new Yocto BSP + + SYNOPSIS + yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] + [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] + + DESCRIPTION + This command creates a Yocto BSP based on the specified + parameters. The new BSP will be a new Yocto BSP layer contained + by default within the top-level directory specified as + 'meta-bsp-name'. The -o option can be used to place the BSP layer + in a directory with a different name and location. + + The value of the 'karch' parameter determines the set of files + that will be generated for the BSP, along with the specific set of + 'properties' that will be used to fill out the BSP-specific + portions of the BSP. + + ... + + NOTE: Once created, you should add your new layer to your + bblayers.conf file in order for it to be subsequently seen and + modified by the yocto-kernel tool. + + NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the + presence of the of the meta-intel layer, so you should also have a + meta-intel layer present and added to your bblayers.conf as well. + </literallayout> + </para> + + <para> + Now that you know where these two commands reside and how to access information + on them, you should find it relatively straightforward to discover the commands + necessary to create a BSP and perform basic kernel maintenance on that BSP using + the tools. + The next sections provide a concrete starting point to expand on a few points that + might not be immediately obvious or that could use further explanation. + </para> + </section> + + + <section id='creating-a-new-bsp-layer-using-the-yocto-bsp-script'> + <title>Creating a new BSP Layer Using the yocto-bsp Script</title> + + <para> + The <filename>yocto-bsp</filename> script creates a new + <link linkend='bsp-layers'>BSP layer</link> for any architecture supported + by the Yocto Project, as well as QEMU versions of the same. + The default mode of the script's operation is to prompt you for information needed + to generate the BSP layer. + For the current set of BSPs, the script prompts you for various important + parameters such as: + <itemizedlist> + <listitem><para>which kernel to use</para></listitem> + <listitem><para>which branch of that kernel to use (or re-use)</para></listitem> + <listitem><para>whether or not to use X, and if so, which drivers to use</para></listitem> + <listitem><para>whether to turn on SMP</para></listitem> + <listitem><para>whether the BSP has a keyboard</para></listitem> + <listitem><para>whether the BSP has a touchscreen</para></listitem> + <listitem><para>any remaining configurable items associated with the BSP</para></listitem> + </itemizedlist> + </para> + + <para> + You use the <filename>yocto-bsp create</filename> sub-command to create + a new BSP layer. + This command requires you to specify a particular architecture on which to + base the BSP. + Assuming you have sourced the environment, you can use the + <filename>yocto-bsp list karch</filename> sub-command to list the + architectures available for BSP creation as follows: + <literallayout class='monospaced'> + $ yocto-bsp list karch + Architectures available: + arm + powerpc + i386 + mips + x86_64 + qemu + </literallayout> + </para> + + <para> + The remainder of this section presents an example that uses + <filename>myarm</filename> as the machine name and <filename>qemu</filename> + as the machine architecture. + Of the available architectures, <filename>qemu</filename> is the only architecture + that causes the script to prompt you further for an actual architecture. + In every other way, this architecture is representative of how creating a BSP for + a 'real' machine would work. + The reason the example uses this architecture is because it is an emulated architecture + and can easily be followed without requiring actual hardware. + </para> + + <para> + As the <filename>yocto-bsp create</filename> command runs, default values for + the prompts appear in brackets. + Pressing enter without supplying anything on the command line or pressing enter + and providing an invalid response causes the script to accept the default value. + </para> + + <para> + Following is the complete example: + <literallayout class='monospaced'> + $ yocto-bsp create myarm qemu + Which qemu architecture would you like to use? [default: x86] + 1) common 32-bit x86 + 2) common 64-bit x86 + 3) common 32-bit ARM + 4) common 32-bit PowerPC + 5) common 32-bit MIPS + 3 + Would you like to use the default (3.2) kernel? (Y/n) + Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n] + Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2... + Please choose a machine branch to base this BSP on => [default: standard/default/common-pc] + 1) base + 2) standard/base + 3) standard/default/arm-versatile-926ejs + 4) standard/default/base + 5) standard/default/beagleboard + 6) standard/default/cedartrailbsp (copy).xml + 7) standard/default/common-pc-64/base + 8) standard/default/common-pc-64/jasperforest + 9) standard/default/common-pc-64/romley + 10) standard/default/common-pc-64/sugarbay + 11) standard/default/common-pc/atom-pc + 12) standard/default/common-pc/base + 13) standard/default/crownbay + 14) standard/default/emenlow + 15) standard/default/fishriver + 16) standard/default/fri2 + 17) standard/default/fsl-mpc8315e-rdb + 18) standard/default/mti-malta32-be + 19) standard/default/mti-malta32-le + 20) standard/default/preempt-rt + 21) standard/default/qemu-ppc32 + 22) standard/default/routerstationpro + 23) standard/preempt-rt/base + 24) standard/preempt-rt/qemu-ppc32 + 25) standard/preempt-rt/routerstationpro + 26) standard/tiny + 3 + Do you need SMP support? (Y/n) + Does your BSP have a touchscreen? (y/N) + Does your BSP have a keyboard? (Y/n) + New qemu BSP created in meta-myarm + </literallayout> + Let's take a closer look at the example now: + <orderedlist> + <listitem><para>For the <filename>qemu</filename> architecture, + the script first prompts you for which emulated architecture to use. + In the example, we use the <filename>arm</filename> architecture. + </para></listitem> + <listitem><para>The script then prompts you for the kernel. + The default kernel is 3.2 and is acceptable. + So, the example accepts the default. + If you enter 'n', the script prompts you to further enter the kernel + you do want to use (e.g. 3.0, 3.2_preempt-rt, etc.).</para></listitem> + <listitem><para>Next, the script asks whether you would like to have a new + branch created especially for your BSP in the local + <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink> + Git repository . + If not, then the script re-uses an existing branch.</para> + <para>In this example, the default (or 'yes') is accepted. + Thus, a new branch is created for the BSP rather than using a common, shared + branch. + The new branch is the branch committed to for any patches you might later add. + The reason a new branch is the default is that typically + new BSPs do require BSP-specific patches. + The tool thus assumes that most of time a new branch is required. + <note>In the current implementation, creation or re-use of a branch does + not actually matter. + The reason is because the generated BSPs assume that patches and + configurations live in recipe-space, which is something that can be done + with or without a dedicated branch. + Generated BSPs, however, are different. + This difference becomes significant once the tool's 'publish' functionality + is implemented.</note></para></listitem> + <listitem><para>Regardless of which choice is made in the previous step, + you are now given the opportunity to select a particular machine branch on + which to base your new BSP-specific machine branch on + (or to re-use if you had elected to not create a new branch). + Because this example is generating an <filename>arm</filename> BSP, the example + uses <filename>#3</filename> at the prompt, which selects the arm-versatile branch. + </para></listitem> + <listitem><para>The remainder of the prompts are routine. + Defaults are accepted for each.</para></listitem> + <listitem><para>By default, the script creates the new BSP Layer in the + <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project + Build Directory</ulink>.</para></listitem> + </orderedlist> + </para> + + <para> + Once the BSP Layer is created, you must add it to your + <filename>bblayers.conf</filename> file. + Here is an example: + <literallayout class='monospaced'> + BBLAYERS = " \ + /usr/local/src/yocto/meta \ + /usr/local/src/yocto/meta-yocto \ + /usr/local/src/yocto/meta-myarm \ + " + </literallayout> + Adding the layer to this file allows the build system to build the BSP and + the <filename>yocto-kernel</filename> tool to be able to find the layer and + other metadata it needs on which to operate. + </para> + </section> + + <section id='managing-kernel-patches-and-config-items-with-yocto-kernel'> + <title>Managing Kernel Patches and Config Items with yocto-kernel</title> + + <para> + Assuming you have created a Yocto Project + <link linkend='bsp-layers'>BSP Layer</link> using + <link linkend='creating-a-new-bsp-layer-using-the-yocto-bsp-script'> + <filename>yocto-bsp</filename></link> and you added it to your + <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink> + variable in the <filename>bblayers.conf</filename> file, you can now use + the <filename>yocto-kernel</filename> script to add patches and configuration + items to the BSP's kernel. + </para> + + <para> + The <filename>yocto-kernel</filename> script allows you to add, remove, and list patches + and kernel config settings to a Yocto Project BSP's kernel + <filename>.bbappend</filename> file. + All you need to do is use the appropriate sub-command. + Recall that the easiest way to see exactly what sub-commands are available + is to use the <filename>yocto-kernel</filename> built-in help as follows: + <literallayout class='monospaced'> + $ yocto-kernel + Usage: + + Modify and list Yocto BSP kernel config items and patches. + + usage: yocto-kernel [--version] [--help] COMMAND [ARGS] + + The most commonly used 'yocto-kernel' commands are: + config list List the modifiable set of bare kernel config options for a BSP + config add Add or modify bare kernel config options for a BSP + config rm Remove bare kernel config options from a BSP + patch list List the patches associated with a BSP + patch add Patch the Yocto kernel for a BSP + patch rm Remove patches from a BSP + + See 'yocto-kernel help COMMAND' for more information on a specific command. + </literallayout> + </para> + + <para> + The <filename>yocto-kernel patch add</filename> sub-command allows you to add a + patch to a BSP. + The following example adds two patches to the <filename>myarm</filename> BSP: + <literallayout class='monospaced'> + $ yocto-kernel patch add myarm ~/test.patch + Added patches: + test.patch + + $ yocto-kernel patch add myarm ~/yocto-testmod.patch + Added patches: + yocto-testmod.patch + </literallayout> + <note>Although the previous example adds patches one at a time, it is possible + to add multiple patches at the same time.</note> + </para> + + <para> + You can verify patches have been added by using the + <filename>yocto-kernel patch list</filename> sub-command. + Here is an example: + <literallayout class='monospaced'> + $ yocto-kernel patch list myarm + The current set of machine-specific patches for myarm is: + 1) test.patch + 2) yocto-testmod.patch + </literallayout> + </para> + + <para> + You can also use the <filename>yocto-kernel</filename> script to + remove a patch using the <filename>yocto-kernel patch rm</filename> sub-command. + Here is an example: + <literallayout class='monospaced'> + $ yocto-kernel patch rm myarm + Specify the patches to remove: + 1) test.patch + 2) yocto-testmod.patch + 1 + Removed patches: + test.patch + </literallayout> + </para> + + <para> + Again, using the <filename>yocto-kernel patch list</filename> sub-command, + you can verify that the patch was in fact removed: + <literallayout class='monospaced'> + $ yocto-kernel patch list myarm + The current set of machine-specific patches for myarm is: + 1) yocto-testmod.patch + </literallayout> + </para> + + <para> + In a completely similar way, you can use the <filename>yocto-kernel config add</filename> + sub-command to add one or more kernel config item settings to a BSP. + The following commands add a couple of config items to the + <filename>myarm</filename> BSP: + <literallayout class='monospaced'> + $ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y + Added items: + CONFIG_MISC_DEVICES=y + + $ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y + Added items: + CONFIG_YOCTO_TESTMOD=y + </literallayout> + <note>Although the previous example adds config items one at a time, it is possible + to add multiple config items at the same time.</note> + </para> + + <para> + You can list the config items now associated with the BSP. + Doing so shows you the config items you added as well as others associated + with the BSP: + <literallayout class='monospaced'> + $ yocto-kernel config list myarm + The current set of machine-specific kernel config items for myarm is: + 1) CONFIG_MISC_DEVICES=y + 2) CONFIG_YOCTO_TESTMOD=y + </literallayout> + </para> + + <para> + Finally, you can remove one or more config items using the + <filename>yocto-kernel config rm</filename> sub-command in a manner + completely analogous to <filename>yocto-kernel patch rm</filename>. + </para> + </section> + </section> </chapter> diff --git a/documentation/bsp-guide/style.css b/documentation/bsp-guide/style.css index 9d068a0f56..85b44f3d34 100644 --- a/documentation/bsp-guide/style.css +++ b/documentation/bsp-guide/style.css @@ -654,7 +654,7 @@ hr { .tip, .warning, .caution, .note { - border-color: #aaa; + border-color: #fff; } @@ -662,24 +662,24 @@ hr { .warning table th, .caution table th, .note table th { - border-bottom-color: #aaa; + border-bottom-color: #fff; } .warning { - background-color: #fea; + background-color: #f0f0f2; } .caution { - background-color: #fea; + background-color: #f0f0f2; } .tip { - background-color: #eff; + background-color: #f0f0f2; } .note { - background-color: #dfc; + background-color: #f0f0f2; } .glossary dl dt, @@ -771,6 +771,17 @@ h6, h7{ } +/* +Example of how to stick an image as part of the title. + +div.article .titlepage .title +{ + background-image: url("figures/white-on-black.png"); + background-position: center; + background-repeat: repeat-x; +} +*/ + div.preface .titlepage .title, div.colophon .title, div.chapter .titlepage .title { @@ -936,8 +947,8 @@ table { .tip, .note { - background: #666666; - color: #fff; + background: #f0f0f2; + color: #333; padding: 20px; margin: 20px; } @@ -948,11 +959,26 @@ table { margin: 0em; font-size: 2em; font-weight: bold; - color: #fff; + color: #333; } .tip a, .note a { - color: #fff; + color: #333; text-decoration: underline; } + +.footnote { + font-size: small; + color: #333; +} + +/* Changes the announcement text */ +.tip h3, +.warning h3, +.caution h3, +.note h3 { + font-size:large; + color: #00557D; +} + diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml index 485064daf9..fe216a0332 100644 --- a/documentation/dev-manual/dev-manual-bsp-appendix.xml +++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml @@ -1,17 +1,21 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='dev-manual-bsp-appendix'> <title>BSP Development Example</title> <para> - This appendix provides a complete BSP example. + This appendix provides a complete BSP development example. 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,32 +28,81 @@ <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. + 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. + These commands create a local copy of the Git repository. + By default, the top-level directory of the repository is named <filename>poky</filename>: + <literallayout class='monospaced'> + $ git clone git://git.yoctoproject.org/poky + $ cd poky + </literallayout> + Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball. + These commands unpack the tarball into a Yocto Project File directory structure. + By default, the top-level directory of the file structure is named + <filename>&YOCTO_POKY;</filename>: + <literallayout class='monospaced'> + $ tar xfj &YOCTO_POKY_TARBALL; + $ cd &YOCTO_POKY; + </literallayout> + <note><para>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 &DISTRO_NAME; release tarballs. + Consequently, there is nothing left to do other than extract those tarballs into the + proper locations.</para> + + <para>Once you expand the released tarball, you have a snapshot of the Git repository + that represents a specific release. + Fundamentally, this is different than having a local copy of the Yocto Project Git repository. - See the bulleted item - "<link linkend='local-yp-release'>Yocto Project Release</link>" - for information on how to get these files. + Given the tarball method, changes you make are building on top of a release. + With the Git repository method you have the ability to track development + and keep changes in revision control.</para></note> </para> <para> - Once you have the local <filename>poky</filename> Git 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: + With the local <filename>poky</filename> Git repository set up, + you have all the development branches available to you from which you can work. + Next, you need to be sure that your local repository reflects the exact + release in which you are interested. + From inside the repository you can see the development branches that represent + areas of development that have diverged from the main (master) branch + at some point, such as a branch to track a maintenance release's development. + You can also see the tag names used to mark snapshots of stable releases or + points in the repository. + Use the following commands to list out the branches and the tags in the repository, + respectively. <literallayout class='monospaced'> $ git branch -a $ git tag -l </literallayout> - For this example we are going to use the Yocto Project 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. + For this example, we are going to use the Yocto Project &DISTRO; Release, which is code + named "&DISTRO_NAME;". + To make sure we have a local area (branch in Git terms) on our machine that + reflects the &DISTRO; release, we can use the following commands: <literallayout class='monospaced'> - $ cd poky - $ git checkout -b edison origin/edison - Switched to a new branch 'edison' + $ cd ~/poky + $ git fetch --tags + $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME; + Switched to a new branch '&DISTRO_NAME;' </literallayout> + The <filename>git fetch --tags</filename> is somewhat redundant since you just set + up the repository and should have all the tags. + The <filename>fetch</filename> command makes sure all the tags are available in your + local repository. + The Git <filename>checkout</filename> command with the <filename>-b</filename> option + creates a local branch for you named <filename>&DISTRO_NAME;</filename>. + Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball + marked with the <filename>&DISTRO_NAME;-&POKYVERSION;</filename> tag in the source repositories. </para> -</section> +</section> <section id='choosing-a-base-bsp-app'> <title>Choosing a Base BSP</title> @@ -58,7 +111,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,29 +131,59 @@ <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 in 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 + <filename>meta-crownbay</filename> 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 Crown Bay tarball. + You can download the &DISTRO_NAME; version of the BSP tarball from the + <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page of the + Yocto Project website. + Here is the specific link for the tarball needed for this example: + <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-1.1/machines/crownbay-noemgd/crownbay-noemgd-edison-6.0.0.tar.bz2'></ulink>. + Again, be sure that you are already in the <filename>poky</filename> directory + as described previously before installing the tarball: + <literallayout class='monospaced'> + $ tar xfj crownbay-noemgd-&DISTRO_NAME;-6.0.0.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 &DISTRO_NAME; 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. + For this example we are going to use the <filename>&DISTRO_NAME;</filename> branch. <literallayout class='monospaced'> - $ cd meta-intel - $ git checkout -b edison origin/edison - Switched to a new branch 'edison' + $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; + Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin. + Switched to a new branch '&DISTRO_NAME;' </literallayout> </para> </section> @@ -112,15 +200,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-<name></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 +247,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,13 +266,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 - Support Packages (BSP) Development Guide</ulink> - for more information on this configuration file. + "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-layer'>Layer Configuration File</ulink>" section + in The Board Support Packages (BSP) Development Guide for more information on this configuration file. Basically, we are changing the existing statements to work with our BSP. </para> @@ -213,7 +302,8 @@ Now we will take a look at the recipes in your new layer. The standard BSP structure has areas for BSP, graphics, core, and kernel recipes. When you create a BSP, you use these areas for appropriate recipes and append files. - Recipes take the form of <filename>.bb</filename> files. + Recipes take the form of <filename>.bb</filename> files, while append files take + the form of <filename>.bbappend</filename> files. If you want to leverage the existing recipes the Yocto Project build system uses but change those recipes, you can use <filename>.bbappend</filename> files. All new recipes and append files for your layer must go in the layer’s @@ -223,7 +313,7 @@ </para> <section id='changing-recipes-bsp'> - <title>Changing <filename>recipes-bsp</filename></title> + <title>Changing <filename>recipes-bsp</filename></title> <para> First, let's look at <filename>recipes-bsp</filename>. @@ -232,7 +322,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> @@ -240,7 +330,7 @@ </section> <section id='changing-recipes-graphics'> - <title>Changing <filename>recipes-graphics</filename></title> + <title>Changing <filename>recipes-graphics</filename></title> <para> Now let's look at <filename>recipes-graphics</filename>. @@ -248,7 +338,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 @@ -262,7 +351,7 @@ </section> <section id='changing-recipes-core'> - <title>Changing <filename>recipes-core</filename></title> + <title>Changing <filename>recipes-core</filename></title> <para> Now let's look at changes in <filename>recipes-core</filename>. @@ -270,7 +359,7 @@ <filename>recipes-core/tasks</filename> appends the similarly named recipe located in the local Yocto Project files at <filename>meta/recipes-core/tasks</filename>. - The "append" file in our layer right now is Crown Bay-specific and supports + The append file in our layer right now is Crown Bay-specific and supports EMGD and non-EMGD. Here are the contents of the file: <literallayout class='monospaced'> @@ -291,7 +380,7 @@ </section> <section id='changing-recipes-kernel'> - <title>Changing <filename>recipes-kernel</filename></title> + <title>Changing <filename>recipes-kernel</filename></title> <para> Finally, let's look at <filename>recipes-kernel</filename> changes. @@ -304,31 +393,38 @@ 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> However, in the <filename>meta-mymachine</filename> layer in <filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename> file named <filename>linux-yocto_3.0.bbappend</filename> that - is appended to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>. - Thus, the <filename>SRCREV</filename> statements in the "append" file override + appends information to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>. + Thus, the <filename>SRCREV</filename> statements in the append file override the more general statements found in <filename>meta</filename>. </para> <para> - The <filename>SRCREV</filename> statements in the "append" file currently identify + The <filename>SRCREV</filename> statements in the append file currently identify the kernel that supports the Crown Bay BSP with and without EMGD support. - Here are the statements: + Here are the statements: + <note>The commit ID strings used in this manual might not match the actual commit + ID strings found in the <filename>linux-yocto_3.0.bbappend</filename> file. + For the example, this difference does not matter.</note> <literallayout class='monospaced'> 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,29 +439,52 @@ </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 &DISTRO_NAME; branch of everything, we + need to use the <filename>SRCREV</filename> values for the atom-pc branch + that are associated with the &DISTRO_NAME; release. + To find those values, we need to find the <filename>SRCREV</filename> + values that &DISTRO_NAME; 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</filename> variable found there. 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 &DISTRO_NAME; release because we're creating a BSP based on + &DISTRO_NAME;. + 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> - branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>. + branch points (commits) for the <filename>linux-yocto-3.0-1.1.x</filename> kernel at + <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.0-1.1.x/'></ulink>. </para> <para> @@ -394,19 +513,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 <filename>atom-pc</filename> branch for this new BSP, we can also find + the exact branch we need for the <filename>KMACHINE</filename> 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 <filename>KMACHINE_atom-pc</filename> 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> @@ -420,7 +545,7 @@ statements that do not support your targeted hardware in addition to the inclusion of any new recipes you might need. In this example, it was simply a matter of ridding the new layer - <filename>meta-machine</filename> of any code that supported the EMGD features + <filename>meta-mymachine</filename> of any code that supported the EMGD features and making sure we were identifying the kernel that supports our example, which is the <filename>atom-pc-standard</filename> kernel. We did not introduce any new recipes to the layer. @@ -455,7 +580,7 @@ Thus, entering the previous command created the <filename>yocto-build</filename> directory. If you do not provide a name for the build directory it defaults to <filename>build</filename>. - The <filename>yocot-build</filename> directory contains a + The <filename>yocto-build</filename> directory contains a <filename>conf</filename> directory that has two configuration files you will need to check: <filename>bblayers.conf</filename> and <filename>local.conf</filename>.</para></listitem> @@ -469,14 +594,14 @@ You should also be sure any other variables in which you are interested are set. Some variables to consider are <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time - if you are using a multi-threaded development system (e.g. values of - <filename>8</filename> and <filename>j 6</filename>, respectively are optimal - for a development machine that has four available cores).</para></listitem> + if your development system supports multiple cores. + For development systems that support multiple cores, a good rule of thumb is to set + both the <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename> + variables to twice the number of cores your system supports.</para></listitem> <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes the path to your new BSP layer. - In this example you need to include the pathname to <filename>meta-mymachine</filename>. - For this example the - <filename>BBLAYERS</filename> variable in the file would need to include the following path: + In this example, you need to include this path as part of the + <filename>BBLAYERS</filename> variable: <literallayout class='monospaced'> $HOME/poky/meta-intel/meta-mymachine </literallayout></para></listitem> @@ -485,14 +610,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='&YOCTO_DOCS_REF_URL;#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 +638,63 @@ 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>.hddimg</filename> file, 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. + <footnote><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 will give you a buildable image that + will probably boot on most systems. + Getting things working like you want + them to for your hardware will normally require some amount of experimentation with + configuration settings.</para></footnote> + </para> + + <para> + For reference, the sato image produced by the previous steps for &DISTRO_NAME; + 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> </section> </appendix> diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manual/dev-manual-intro.xml index 3495cdac6a..0728753358 100644 --- a/documentation/dev-manual/dev-manual-intro.xml +++ b/documentation/dev-manual/dev-manual-intro.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='dev-manual-intro'> @@ -15,9 +16,10 @@ using the Yocto Project. Because much of the information in this manual is general, it contains many references to other sources where you can find more detail. - For example, detailed information on Git, repositories and open-source in general + For example, detailed information on Git, repositories and open source in general can be found in many places. - Another example is how to get set up to use the Yocto Project, which our Yocto Project Quick Start covers. + Another example is how to get set up to use the Yocto Project, which our + <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink> covers. </para> <para> @@ -35,10 +37,10 @@ <itemizedlist> <listitem><para>Information that lets you get set up to develop using the Yocto Project.</para></listitem> - <listitem><para>Information to help developers that are new to the open source environment + <listitem><para>Information to help developers who are new to the open source environment and to the distributed revision control system Git, which the Yocto Project uses.</para></listitem> - <listitem><para>An understanding of common end-to-end development models.</para></listitem> + <listitem><para>An understanding of common end-to-end development models and tasks.</para></listitem> <listitem><para>Development case overviews for both system development and user-space applications.</para></listitem> <listitem><para>An overview and understanding of the emulation environment used with @@ -63,13 +65,15 @@ <itemizedlist> <listitem><para>Step-by-step instructions if those instructions exist in other Yocto Project documentation. - For example, The Application Development Toolkit (ADT) User’s Guide contains detailed + For example, the + <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Development Toolkit (ADT) + User's Guide</ulink> contains detailed instruction on how to obtain and configure the <trademark class='trade'>Eclipse</trademark> Yocto Plug-in.</para></listitem> <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='&YOCTO_DOCS_REF_URL;'> 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 @@ -86,31 +90,31 @@ need to supplement it with other information. The following list presents other sources of information you might find helpful: <itemizedlist> - <listitem><para><emphasis>The <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>: + <listitem><para><emphasis>The <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>: </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='&YOCTO_DOCS_QS_URL;'> 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='&YOCTO_DOCS_REF_URL;'> 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='&YOCTO_DOCS_ADT_URL;'> 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='&YOCTO_DOCS_BSP_URL;'> 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='&YOCTO_DOCS_KERNEL_URL;'> 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> @@ -120,14 +124,14 @@ demonstrates how an application developer uses Yocto Plug-in features within the Eclipse IDE.</para></listitem> <listitem><para><emphasis> - <ulink url='http://wiki.yoctoproject.org/wiki/FAQ'>FAQ</ulink>:</emphasis> + <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis> A list of commonly asked questions and their answers.</para></listitem> <listitem><para><emphasis> - <ulink url='http://www.yoctoproject.org/download/yocto/yocto-project-1.0-release-notes-poky-5.0'> + <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-1.1.2-release-notes-poky-&POKYVERSION;'> Release Notes</ulink>:</emphasis> Features, updates and known issues for the current release of the Yocto Project.</para></listitem> <listitem><para><emphasis> - <ulink url='http://bugzilla.yoctoproject.org/'>Bugzilla</ulink>:</emphasis> + <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:</emphasis> The bug tracking application the Yocto Project uses. If you find problems with the Yocto Project, you should report them using this application.</para></listitem> @@ -135,11 +139,11 @@ Yocto Project Mailing Lists:</emphasis> To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions: <itemizedlist> - <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a + <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> for a Yocto Project Discussions mailing list.</para></listitem> - <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a + <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> for a Yocto Project Discussions mailing list about the Poky build system.</para></listitem> - <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink> + <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> for a mailing list to receive offical Yocto Project announcements for developments and as well as Yocto Project milestones.</para></listitem> </itemizedlist></para></listitem> @@ -148,20 +152,20 @@ for Yocto Project and Poky discussions: <filename>#yocto</filename> and <filename>#poky</filename>.</para></listitem> <listitem><para><emphasis> - <ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis> + <ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis> The company where the Yocto Project build system Poky was first developed. OpenedHand has since been acquired by Intel Corporation.</para></listitem> <listitem><para><emphasis> <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis> - The company who acquired OpenedHand in 2008 and continues development on the + The company that acquired OpenedHand in 2008 and continues development on the Yocto Project.</para></listitem> <listitem><para><emphasis> - <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis> + <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis> The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives from and to which it contributes.</para></listitem> <listitem><para><emphasis> <ulink url='http://developer.berlios.de/projects/bitbake/'> - Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem> + BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem> <listitem><para><emphasis> <ulink url='http://bitbake.berlios.de/manual/'> BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool. diff --git a/documentation/dev-manual/dev-manual-kernel-appendix.xml b/documentation/dev-manual/dev-manual-kernel-appendix.xml index 533875b040..d988f046d1 100644 --- a/documentation/dev-manual/dev-manual-kernel-appendix.xml +++ b/documentation/dev-manual/dev-manual-kernel-appendix.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='dev-manual-kernel-appendix'> @@ -65,7 +66,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 +76,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,14 +150,14 @@ $ git branch -a $ git tag -l </literallayout> - This example uses the Yocto Project 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> + This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", + which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. + The following commands create and checkout the local <filename>&DISTRO_NAME;</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' + $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; + Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin. + Switched to a new branch '&DISTRO_NAME;' </literallayout> </para> </section> @@ -171,13 +173,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/poky-extras + $ git branch -a + $ git tag -l + </literallayout> + This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", + which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. + The following commands create and checkout the local <filename>&DISTRO_NAME;</filename> + branch: + <literallayout class='monospaced'> + $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; + Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin. + Switched to a new branch '&DISTRO_NAME;' + </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 +212,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' @@ -221,12 +245,12 @@ 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. + As a guideline, set both <filename>BB_NUMBER_THREADS</filename> and + <filename>PARALLEL_MAKE</filename> to twice 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 +313,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. @@ -388,9 +412,8 @@ build time if your host supports multi-core and multi-thread capabilities: <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>. If the host system has multiple cores then you can optimize build time - by setting <filename>BB_NUMBER_THREADS</filename> to twice the number of - cores and setting <filename>PARALLEL_MAKE</filename> to one and a half times the - number of cores.</para></listitem> + by setting both these variables to twice the number of + cores.</para></listitem> <listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename> Layer:</emphasis> The <filename>BBLAYERS</filename> variable in the <filename>bblayers.conf</filename> file found in the @@ -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 @@ -432,14 +455,19 @@ </para> <note> - Before attempting to build the modified kernel, there is one more set of changes you + <para>Before attempting to build the modified kernel, there is one more set of changes you need to make in the <filename>meta-kernel-dev</filename> layer. 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, or simply remove (or rename) all the files except the one your are using for the build - (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example). + (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).</para> + <para>If you do not make one of these two adjustments, your machine will be compatible + with all the kernel recipes in the <filename>meta-kernel-dev</filename> layer. + When your machine is comapatible with all the kernel recipes, the build attempts + to build all kernels in the layer. + You could end up with build errors blocking your work.</para> </note> </section> @@ -453,18 +481,21 @@ <listitem><para>Your environment should be set up since you previously sourced the <filename>oe-init-build-env</filename> script. If it isn't, source the script again from <filename>poky</filename>. + <literallayout class='monospaced'> + $ cd ~/poky + $ source oe-init-build-env + </literallayout> </para></listitem> <listitem><para>Be sure old images are cleaned out by running the - <filename>cleanall</filename> BitBake task as follows: + <filename>cleanall</filename> BitBake task as follows from your build directory: <literallayout class='monospaced'> - $ cd ~/poky $ bitbake -c cleanall linux-yocto </literallayout></para> <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename> directory insided the local Yocto Project files build directory. Always use the BitBake <filename>cleanall</filename> task to clear out previous builds.</note></para></listitem> - <listitem><para>Build the kernel image using this command: + <listitem><para>Next, build the kernel image using this command: <literallayout class='monospaced'> $ bitbake -k core-image-minimal </literallayout></para></listitem> @@ -508,50 +539,98 @@ 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 the next section, which is 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 &DISTRO; Release code named "&DISTRO_NAME;", + which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. + The following commands create and checkout the local <filename>&DISTRO_NAME;</filename> + branch: + <literallayout class='monospaced'> + $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; + Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin. + Switched to a new branch '&DISTRO_NAME;' + </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 <target>' + + 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'> - <title>Examining the Default <filename>CONFIG_SMP</filename> Behavior</title> + <title>Examining the Default <filename>CONFIG_SMP</filename> Behavior</title> <para> By default, <filename>CONFIG_SMP</filename> supports single processor machines. @@ -577,8 +656,10 @@ </para> </section> + + <section id='changing-the-config-smp-configuration-using-menuconfig'> - <title>Changing the <filename>CONFIG_SMP</filename> Configuration Using <filename>menuconfig</filename></title> + <title>Changing the <filename>CONFIG_SMP</filename> Configuration Using <filename>menuconfig</filename></title> <para> The <filename>menuconfig</filename> tool provides an interactive method with which @@ -596,15 +677,24 @@ <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>. - Thus, the following command from the shell in which you previously sourced the - environment initialization script launches <filename>menuconfig</filename>: + Thus, the following commands from the shell in which you previously sourced the + environment initialization script cleans the shared state memory and + the <filename>WORKDIR</filename> direcotry and then builds and + launches <filename>menuconfig</filename>: <literallayout class='monospaced'> + $ bitbake linux-yocto -c cleansstate $ bitbake linux-yocto -c menuconfig </literallayout> + <note>Due to a bug in the release, it is necessary to clean the shared state + memory in order for configurations made using <filename>menuconfig</filename> + to take effect. + For information on the bug, see + <ulink url='&YOCTO_BUGZILLA_URL;/show_bug.cgi?id=2256'></ulink>. + </note> </para> <para> @@ -622,16 +712,19 @@ is updated. This is the file that the build system uses to configure the Linux Yocto kernel when it is built. - You can find and examine this file in the Yocto Project files Git repository in + You can find and examine this file in the Yocto Project Files Git repository in the build directory. - This example uses the following. - Note that this example directory is artificially split and many of the characters - in the actually filename are omitted in order to make it more - readable: + This example uses the following: <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> + <note> + The previous example directory is artificially split and many of the characters + in the actual filename are omitted in order to make it more readable. + Also, depending on the kernel you are using, the exact pathname might differ + slightly. + </note> </para> <para> diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml index d95382617a..30142a61b3 100644 --- a/documentation/dev-manual/dev-manual-model.xml +++ b/documentation/dev-manual/dev-manual-model.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='dev-manual-model'> @@ -23,9 +24,8 @@ "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix. 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'> - The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>. + see <ulink url='&YOCTO_DOCS_ADT_URL;'>The Yocto Project Application Development + Toolkit (ADT) User's Guide</ulink>. </para> <section id='system-development-model'> @@ -35,8 +35,8 @@ System development involves modification or creation of an image that you want to run on a specific hardware target. Usually, when you want to create an image that runs on embedded hardware, the image does - not require the same amount of features that a full-fledged Linux distribution provides. - Thus, you can create a much smaller image that is designed to just use the hardware + not require the same number of features that a full-fledged Linux distribution provides. + Thus, you can create a much smaller image that is designed to use only the hardware features for your particular hardware. </para> @@ -50,8 +50,8 @@ <title>Developing a Board Support Package (BSP)</title> <para> - A BSP is a package of recipes that, when applied, during a build results in - an image you can run on a particular board. + A BSP is a packageof recipes that, when applied, during a build results in + an image that you can run on a particular board. Thus, the package, when compiled into the new image, supports the operation of the board. </para> @@ -61,8 +61,8 @@ </note> <para> - The remainder of this section presents the basic steps to create a BSP basing it on an - existing BSP that ships with the Yocto Project. + The remainder of this section presents the basic steps used to create a BSP + based on an existing BSP that ships with the Yocto Project. You can reference the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>" appendix for a detailed example that uses the Crown Bay BSP as a base BSP from which to start. </para> @@ -79,18 +79,19 @@ <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='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" + and the + "<ulink url='&YOCTO_DOCS_QS_URL;#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. Having the Yocto Project files on your system gives you access to the build - process and tools you need. + process and to the tools you need. For information on how to get these files, see the "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem> <listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>: Having the BSP files on your system gives you access to the build - process and tools you need for creating a BSP. + process and to the tools you need for creating a BSP. For information on how to get these files, see the "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem> <listitem><para><emphasis>Choose a Yocto Project-supported BSP as your base BSP</emphasis>: @@ -111,13 +112,15 @@ Crown Bay that does not support the <trademark class='registered'>Intel</trademark> Embedded Media Graphics Driver (EMGD). The remainder of this example uses that base BSP.</para> - <para>To see the supported BSPs, go to the Yocto Project - <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click - on “BSP Downloads.”</para></listitem> + <para>To see the supported BSPs, go to the + <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page on the Yocto Project + website and click on “BSP Downloads.”</para></listitem> <listitem><para><emphasis>Create your own BSP layer</emphasis>: Layers are ideal for isolating and storing work for a given piece of hardware. - A layer is really just a location or area in which you place the recipes for your BSP. + A layer is really just a location or area in which you place the recipes for your BSP. In fact, a BSP is, in itself, a special type of layer. + </para> + <para> Another example that illustrates a layer is an application. Suppose you are creating an application that has library or other dependencies in order for it to compile and run. @@ -137,16 +140,17 @@ 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='&YOCTO_DOCS_BSP_URL;#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 directory structure of the <filename>meta-crownbay</filename> layer inside the local Yocto Project files.</para></listitem> <listitem><para><emphasis>Make configuration changes to your new BSP - layer</emphasis>: The standard BSP layer structure organizes the files you need to edit in - <filename>conf</filename> and several <filename>recipes-*</filename> directories within the - BSP layer. + layer</emphasis>: The standard BSP layer structure organizes the files you need + to edit in <filename>conf</filename> and several <filename>recipes-*</filename> + directories within the BSP layer. Configuration changes identify where your new layer is on the local system and identify which kernel you are going to use. </para></listitem> @@ -160,7 +164,8 @@ 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='&YOCTO_DOCS_QS_URL;#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 +173,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='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" appendix + in The Yocto Project Reference Manual for information on + supported images.</para></listitem> </orderedlist> </para> @@ -178,10 +183,10 @@ 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='&YOCTO_DOCS_BSP_URL;'> 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'> + <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'> here</ulink> that you might find helpful. </para> </section> @@ -191,7 +196,7 @@ <para> Kernel modification involves changing the Linux Yocto kernel, which could involve changing - configuration variables as well as adding new kernel recipes. + configuration options as well as adding new kernel recipes. Configuration changes can be added in the form of configuration fragments, while recipe modification comes through the kernel's <filename>recipes-kernel</filename> area in a kernel layer you create. @@ -201,7 +206,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='&YOCTO_DOCS_KERNEL_URL;'> The Yocto Project Kernel Architecture and Use Manual</ulink>. You can reference the appendix "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" @@ -212,35 +217,41 @@ <title>Kernel Overview</title> <para> - When one thinks of the source files for a kernel they usually think of a fixed structure - of files that contain kernel patches. - The Yocto Project, however, employs mechanisims, that in a sense, result in a kernel source + Traditionally, when one thinks of a patched kernel, they think of a base kernel + source tree and a fixed structure that contains kernel patches. + The Yocto Project, however, employs mechanisms, that in a sense, result in a kernel source generator. By the end of this section, this analogy will become clearer. </para> <para> You can find a web interface to the Linux Yocto kernel source repositories at - <ulink url='http://git.yoctoproject.org/'></ulink>. + <ulink url='&YOCTO_GIT_URL;'></ulink>. If you look at the interface, you will see to the left a grouping of Git repositories titled "Yocto Linux Kernel." - Within this group, you will find the four different kernels supported by + Within this group, you will find several kernels supported by the Yocto Project: <itemizedlist> <listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The 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 + <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable Linux Yocto kernel that 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-3.2</filename></emphasis> - The + stable Linux Yocto kernel to use with the Yocto Project Release 1.2. This kernel + is based on the Linux 3.2 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> </para> <para> - The kernels are maintained using the Git application that, in a sense, structures - them in a "tree" complete with branches and leaves. + The kernels are maintained using the Git revision control system + that structures them using the familiar "tree", "branch", and "leaf" scheme. Branches represent diversions from general code to more specific code, while leaves represent the end-points for a complete and unique kernel whose source files when gathered from the root of the tree to the leaf accumulate to create the files @@ -253,7 +264,7 @@ <para> Within the figure, the "Kernel.org Branch Point" represents the point in the tree - where a supported base kernel diverges from the Linux kernel. + where a supported base kernel is modified from the Linux kernel. For example, this could be the branch point for the <filename>linux-yocto-3.0</filename> kernel. Thus, everything further to the right in the structure is based on the @@ -267,14 +278,14 @@ <para> The overall result is a Git-maintained repository from which all the supported - Yocto Project kernels can be derived for all the supported Yocto Project devices. + Yocto Project kernel types can be derived for all the supported Yocto Project devices. A big advantage to this scheme is the sharing of common features by keeping them in "larger" branches within the tree. This practice eliminates redundant storage of similar features shared among kernels. </para> <note> - Keep in mind the figure does not take into account all four supported Linux Yocto + Keep in mind the figure does not take into account all the supported Linux Yocto kernel types, but rather shows a single generic kernel just for conceptual purposes. Also keep in mind that this structure represents the Yocto Project source repositories that are either pulled from during the build or established on the host development system @@ -311,7 +322,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,11 +360,11 @@ <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 <ulink url='&YOCTO_DOCS_KERNEL_URL;'> 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> - for a detailed example that modifies the kernel. + You can also reference the + "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</link>" + section for a detailed example that modifies the kernel. </para> </section> @@ -373,8 +384,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='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and + "<ulink url='&YOCTO_DOCS_QS_URL;#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 @@ -390,7 +401,10 @@ Project files Git repository. For information on how to get these files, see the bulleted item "<link linkend='poky-extras-repo'>The <filename>poky-extras</filename> Git Repository</link>" - earlier in this manual.</para></listitem> + earlier in this manual. + <note>While it is certainly possible to modify the kernel without involving + a local Git repository, the suggested workflow for kernel modification + using the Yocto Project does use a Git repository.</note></para></listitem> <listitem><para><emphasis>Establish a local copy of the Linux Yocto kernel files on your system</emphasis>: In order to make modifications to the kernel you need two things: a bare clone of the Linux Yocto kernel you are modifying and @@ -412,7 +426,7 @@ Once the changes are made, you need to use Git commands to commit the changes and then push them to the bare clone.</para></listitem> <listitem><para><emphasis>Make kernel configuration changes - to your local kernel layer if applicable</emphasis>: + if applicable</emphasis>: If your situation calls for changing the kernel's configuration, you can use <filename>menuconfig</filename> to enable and disable kernel configurations. @@ -420,11 +434,18 @@ configuration changes you are making to the kernel. When saved, changes using <filename>menuconfig</filename> update the kernel's <filename>.config</filename>. - As an alternative method to changing the kernel's configuration, you can simply - edit the <filename>.config</filename> found in the Yocto Project build - directory at <filename>tmp/sysroots/<machine-name>/kernel</filename> - directly.</para></listitem> - <listitem><para><emphasis>Add new kernel recipes if applicable</emphasis>: The standard + Try to resist the temptation of directly editing the <filename>.config</filename> + file found in the Yocto Project build directory at + <filename>tmp/sysroots/<machine-name>/kernel</filename>. + Doing so, can produce unexpected results when the Yocto Project build system + regenerates the configuration file.</para> + <para>Once you are satisfied with the configuration changes made using + <filename>menuconfig</filename>, you can directly examine the + <filename>.config</filename> file against a saved original and gather those + changes into a config fragment to be referenced from within the kernel's + <filename>.bbappend</filename> file.</para></listitem> + <listitem><para><emphasis>Add or extend kernel recipes if applicable</emphasis>: + The standard layer structure organizes recipe files inside the <filename>meta-kernel-dev</filename> layer that is within the <filename>poky-extras</filename> Git repository. @@ -436,14 +457,15 @@ <listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the changes to your kernel (configurations, source code changes, recipe additions, or recipe changes), there remains a few things - you need to do in order for the Yocto Project build system to create your image. + you need to do in order for the Yocto Project build system (BitBake) to create your image. If you have not done so, you need to get the build environment ready by sourcing the environment setup script described earlier. You also need to be sure two key configuration files (<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='&YOCTO_DOCS_QS_URL;#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 +476,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='&YOCTO_DOCS_REF_URL;#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. @@ -465,10 +485,10 @@ which allows you to distribute the layer.</para></listitem> <listitem><para><emphasis>If applicable, share your in-tree changes</emphasis>: If the changes you made - are suited for all Linux Yocto users, you might want to push the changes to a - contribution area for the Linux Yocto Git repository. - Once the changes are pushed, you can request that they - be pulled into the master branch of the kernel tree. + are suited for all Linux Yocto users, you might want to send them on for inclusion + into the Linux Yocto Git repository. + If the changes are accepted, the Yocto Project Maintainer pulls them into + the master branch of the kernel tree. Doing so makes them available to everyone using the kernel.</para></listitem> </orderedlist> </para> @@ -507,7 +527,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='&YOCTO_DOCS_ADT_URL;'> The Application Development Toolkit (ADT) User's Manual</ulink>. </para> @@ -524,8 +544,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='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and + "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both in the Yocto Project Quick Start for requirements.</para></listitem> <!-- @@ -550,15 +570,15 @@ WRITER NOTE: The areas to get the kernel and root filesystem are located in the You must have a target kernel image that has been built using the Yocto Project.</para> <para>Depending on whether the Yocto Project has a pre-built image that matches your target architecture and where you are going to run the image while you develop your application - (QEMU or real hardware), the area you get the image from differs. + (QEMU or real hardware), the area from which you get the image differs. <itemizedlist> <listitem><para>Download the image from - <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/'> + <ulink url='&YOCTO_MACHINES_DL_URL;'> <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='&YOCTO_QEMU_DL_URL;'> <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,10 +593,8 @@ 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>" - section in - <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'> - The Yocto Project Quick Start</ulink>.</para></listitem> + "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>" + section in the Yocto Project Quick Start.</para></listitem> <listitem><para><emphasis>Install the ADT</emphasis>: The ADT provides a target-specific cross-development toolchain, the root filesystem, the QEMU emulator, and other tools that can help you develop your application. @@ -584,9 +602,9 @@ 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 - Application Development (ADT) User's Manual</ulink>.</para></listitem> + "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>" + section + in the Yocto Project Application Development (ADT) User's Manual.</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, you need to find and download the @@ -630,14 +648,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 - Application Development (ADT) User's Manual</ulink>.</para></listitem> + "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" + section + in the Yocto Project Application Development (ADT) User's Manual.</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='&YOCTO_MACHINES_DL_URL;'> <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 +665,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='&YOCTO_QEMU_DL_URL;'> <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 +673,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='&YOCTO_DOCS_ADT_URL;#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. diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 08b4747480..774ac3d5bf 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='dev-manual-newbie'> @@ -7,11 +8,11 @@ <para> This chapter helps you understand the Yocto Project as an open source development project. - In general, working in an open source environment is very different as compared to working in a - proprietary environment. + In general, working in an open source environment is very different from working in a + closed, proprietary environment. Additionally, the Yocto Project uses specific tools and constructs as part of its development environment. - The chapter specifically addresses open source philosophy, licensing issues, code repositories, + This chapter specifically addresses open source philosophy, licensing issues, code repositories, the open source distributed version control system Git, and best practices using the Yocto Project. </para> @@ -20,10 +21,10 @@ <para> Open source philosophy is characterized by software development directed by peer production - and collaboration through a concerned community of developers. + and collaboration through an active community of developers. Contrast this to the more standard centralized development models used by commercial software companies where a finite set of developers produce a product for sale using a defined set - of procedures that ultimately result in an end-product whose architecture and source material + of procedures that ultimately result in an end product whose architecture and source material are closed to the public. </para> @@ -33,7 +34,7 @@ stake in the software project. The open source environment contains new copyright, licensing, domain, and consumer issues that differ from the more traditional development environment. - In an open source environment, the end-product, source material, and documentation are + In an open source environment, the end product, source material, and documentation are all available to the public at no cost. </para> @@ -58,7 +59,7 @@ <para> The Yocto Project team maintains complete source repositories for all Yocto Project files - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>here</ulink>. + at <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>. This web-based source code browser is organized into categories by function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the interface, you can click on any particular item in the "Name" column and @@ -73,13 +74,13 @@ Conversely, if you are a developer that is not interested in contributing back to the Yocto Project, you have the ability to simply download and extract release tarballs and use them within the Yocto Project environment. - All that is required is a particular release of Yocto Project, a kernel, and + All that is required is a particular release of the Yocto Project and your application source code. </para> <para> For any supported release of Yocto Project, you can go to the Yocto Project website’s - <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and get a + <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> and get a tarball of the release. You can also go to this site to download any supported BSP tarballs. Unpacking the tarball gives you a hierarchical directory structure of Yocto Project @@ -94,15 +95,15 @@ <para> In summary, here is where you can get the Yocto Project files needed for development: <itemizedlist> - <listitem><para><emphasis><ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis> + <listitem><para><emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis> This area contains IDE Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and Yocto Metadata Layers. You can create Git repositories for each of these areas.</para> <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='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis> + This area contains 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. @@ -111,11 +112,11 @@ <para> <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" /> </para></listitem> - <listitem><para><emphasis><ulink url='http://www.yoctoproject.org/download'>Yocto Project Download Page</ulink></emphasis> + <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;/download'>Yocto Project Download Page</ulink></emphasis> 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='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> area.</para> <para> <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" /> </para></listitem> @@ -170,10 +171,8 @@ 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>" - appendix in - <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'> - The Yocto Project Reference Manual</ulink>.</para></listitem> + "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" + appendix in the Yocto Project Reference Manual.</para></listitem> <listitem><para><emphasis>Layer:</emphasis> A collection of recipes representing the core, a BSP, or an application stack.</para></listitem> <listitem><para><emphasis>Metadata:</emphasis> The files that BitBake parses when building an image. @@ -216,14 +215,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>&YOCTO_POKY_TARBALL;</filename> results in a Yocto Project file structure whose Yocto Project source directory is named - <filename>poky-edison-6.0</filename>. + <filename>&YOCTO_POKY;</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='&YOCTO_DOCS_DEV_URL;#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 +232,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-&POKYVERSION;</filename>: <literallayout class='monospaced'> - $ source poky-edison-6.0/oe-init-build-env $HOME/mybuilds/YP-6.0 + $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION; </literallayout> If you don't specifically name the directory, BitBake creates it in the current directory and uses the name <filename>build</filename>. @@ -305,7 +304,7 @@ <para> You can find a list of the combined SPDX and OSI licenses that the Yocto Project uses - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>. + <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>. This wiki page discusses the license infrastructure used by the Yocto Project. </para> </section> @@ -316,7 +315,10 @@ <para> The Yocto Project uses Git, which is a free, open source distributed version control system. Git supports distributed development, non-linear development, and can handle large projects. - It is best that you know how to work with Git if you are going to use Yocto Project for development. + It is best that you have some fundamental understanding of how Git tracks projects and + how to work with Git if you are going to use Yocto Project for development. + This section provides a quick overview of how Git works and provides you with a summary + of some essential Git commands. </para> <para> @@ -423,7 +425,7 @@ In particular, the information covers basic practices that describe roles and actions in a collaborative development environment. Again, if you are familiar with this type of development environment, you might want to just - skip the section. + skip this section. </para> <para> @@ -436,7 +438,7 @@ The maintainer is responsible for allowing changes in from other developers and for organizing the underlying branch structure to reflect release strategies and so forth. <note>You can see who is the maintainer for Yocto Project files by examining the - <filename>distro_tracking_fields</filename> file in the Yocto Project + <filename>distro_tracking_fields.inc</filename> file in the Yocto Project <filename>meta/conf/distro/include</filename> directory.</note> </para> @@ -475,7 +477,7 @@ "master" branch of the Git repository, which is controlled by the project’s maintainer. And, we have a set of developers who independently develop, test, and submit changes to "contrib" areas for the maintainer to examine. - The maintainer then chooses which changes are going to become permanently a part of the project. + The maintainer then chooses which changes are going to become a permanent part of the project. </para> <para> @@ -486,15 +488,18 @@ 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 + <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep the changes you commit small as compared to bundling many disparate changes into a single commit. This practice not only keeps things manageable but also allows the maintainer to more easily include or refuse changes.</para> <para>It is also good practice to leave the repository in a state that allows you to - still successfully build your project.</para></listitem> + still successfully build your project. In other words, do not commit half of a feature, + then add the other half in a separate, later commit. + Each commit should take you from one buildable project state to another + buildable state.</para></listitem> <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and delete local branches in your working Git repository. You can name these branches anything you like. @@ -527,7 +532,7 @@ <filename>send-pull-request</filename> that ship with the release to facilitate this workflow. You can find these scripts in the local Yocto Project files Git repository in - <filename>scripts</filename>.</para></listitem> + the <filename>scripts</filename> directory.</para></listitem> <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the maintainer through an email that you have a change (or patch) you would like considered for the "master" branch of the Git repository. @@ -548,7 +553,7 @@ 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. The home page for the Yocto Project implementation of Bugzilla is - <ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>. + <ulink url='&YOCTO_BUGZILLA_URL;'>&YOCTO_BUGZILLA_URL;</ulink>. </para> <para> @@ -559,7 +564,7 @@ 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>. + <ulink url='&YOCTO_WIKI_URL;/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> @@ -602,27 +607,28 @@ <para> Contributions to the Yocto Project are very welcome. + Because the Yocto Project is extremely configurable and flexible, we recognize that developers + will want to extend, configure or optimize it for their specific uses. 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 - Yocto Project Reference Manual</ulink>. + "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in + The Yocto Project Reference Manual. </para> <para> - Following is some guidance on which mailing list to use for what type of defect: + The following is some guidance on which mailing list to use for what type of defect: <itemizedlist> <listitem><para>For defects against the Yocto Project build system Poky, send your patch to the - <ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> mailing list. + <ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> mailing list. This mailing list corresponds to issues that are not specific to the Yocto Project but are part of the OE-core. For example, a defect against anything in the <filename>meta</filename> layer or the BitBake Manual could be sent to this mailing list.</para></listitem> <listitem><para>For defects against Yocto-specific layers, tools, and Yocto Project documentation use the - <ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> mailing list. + <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> mailing list. This mailing list corresponds to Yocto-specific areas such as <filename>meta-yocto</filename>, <filename>meta-intel</filename>, <filename>linux-yocto</filename>, and <filename>documentation</filename>.</para></listitem> @@ -630,7 +636,7 @@ </para> <para> - When you send a patch, be sure to include a "signed-off-by:" + When you send a patch, be sure to include a "Signed-off-by:" line in the same style as required by the Linux kernel. Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1 as follows: @@ -672,11 +678,14 @@ <para> In a collaborative environment, it is necessary to have some sort of standard or method through which you submit changes. - Otherwise, things could get quite chaotic. + Otherwise, things could get quite chaotic. + One general practice to follow is to make small, controlled changes to the + Yocto Project. + Keeping changes small and isolated lets you best keep pace with future Yocto Project changes. </para> <para> - When you form a commit, you must follow certain standards established by the + When you create a commit, you must follow certain standards established by the Yocto Project development team. For each commit, you must provide a single-line summary of the change and you almost always provide a more detailed description of what you did (i.e. the body @@ -710,7 +719,7 @@ <para> You can find more guidance on creating well-formed commit messages at this OpenEmbedded wiki page: - <ulink url='http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines'></ulink>. + <ulink url='&OE_HOME_URL;/wiki/Commit_Patch_Message_Guidelines'></ulink>. </para> <para> @@ -748,9 +757,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> @@ -775,7 +783,7 @@ See the earlier section "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" for Yocto Project commit message standards.</para></listitem> - <listitem><para>Format the commit into an email messsage. + <listitem><para>Format the commit into an email message. To format commits, use the <filename>git format-patch</filename> command. When you provide the command, you must include a revision list or a number of patches as part of the command. @@ -790,6 +798,11 @@ <para>If you provide several commits as part of the command, the <filename>git format-patch</filename> command produces a numbered series of files in the current directory – one for each commit. + If you have more than one patch, you should also use the + <filename>--cover</filename> option with the command, which generates a + cover letter as the first "patch" in the series. + You can then edit the cover letter to provide a description for + the series of patches. For information on the <filename>git format-patch</filename> command, see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the <filename>man git-format-patch</filename> command.</para></listitem> @@ -802,7 +815,15 @@ or remote Mail Transport Agent (MTA) such as <filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct <filename>smtp</filename> configuration in your Git <filename>config</filename> - file.</para> + file. + If you are submitting patches through email only, it is very important + that you submit them without any whitespace or HTML formatting that + either you or your mailer introduces. + The maintainer that receives your patches needs to be able to save and + apply them directly from your emails. + A good way to verify that what you are sending will be applicable by the + maintainer is to do a dry run and send them to yourself and then + save and apply them as the maintainer would.</para> <para>The <filename>git send-email</filename> command is the preferred method for sending your patches since there is no risk of compromising whitespace in the body of the message, which can occur when you use your own mail client. diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml index a5f3652b13..d7a046b5c0 100644 --- a/documentation/dev-manual/dev-manual-start.xml +++ b/documentation/dev-manual/dev-manual-start.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='dev-manual-start'> @@ -9,7 +10,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='&YOCTO_DOCS_QS_URL;'> The Yocto Project Quick Start</ulink>. </para> @@ -30,20 +31,21 @@ </para> <para> - You can use the Yocto Project, which uses the BitBake build tool, to develop complete Linux + You can use the Yocto Project build system, which uses + <ulink url='http://bitbake.berlios.de/manual/'>BitBake</ulink>, to develop complete Linux images and associated user-space applications for architectures based on ARM, MIPS, PowerPC, x86 and x86-64. While the Yocto Project does not provide a strict testing framework, it does provide or generate for you artifacts that let you perform target-level and emulated testing and debugging. - And, if you are an <trademark class='trade'>Eclipse</trademark> + Additionally, if you are an <trademark class='trade'>Eclipse</trademark> IDE user, you can install an Eclipse Yocto Plug-in to allow you to develop within that familiar environment. </para> </section> <section id='getting-setup'> - <title>Getting Setup</title> + <title>Getting Set Up</title> <para> Here is what you need to get set up to use the Yocto Project: @@ -57,7 +59,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='&YOCTO_DOCS_QS_URL;#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> @@ -73,29 +75,37 @@ <itemizedlist> <listitem><para><emphasis>Tarball Extraction:</emphasis> If you are not going to contribute 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>. + from the website’s <ulink url='&YOCTO_HOME_URL;/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 &DISTRO; + 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>&YOCTO_POKY;</filename>: <literallayout class='monospaced'> - $ tar xfj poky-edison-6.0.tar.bz2 + $ tar xfj &YOCTO_POKY_TARBALL; </literallayout></para> <para>This method does not produce a Git repository. Instead, you simply end up with a local snapshot of the Yocto Project files that are based on the particular release in the tarball.</para></listitem> <listitem><para><emphasis>Git Repository Method:</emphasis> If you are going to be contributing - back into the Yocto Project, you should use Git commands to set up a local - Git repository of the Yocto Project files. + back into the Yocto Project or you simply want to keep up + with the latest developments, you should use Git commands to set up a local + Git repository of the Yocto Project files. Doing so creates a Git repository with a complete history of changes and allows - you to easily submit your changes upstream to the project.</para> - <para>The following transcript shows how to clone the Yocto Project files' - Git repository into the current working directory. - The command creates the repository in a directory named <filename>poky</filename>. - For information on the Yocto Project and Git, see the - "<link linkend='git'>Git</link>" section. - <literallayout class='monospaced'> + you to easily submit your changes upstream to the project. + Because you cloned the repository, you have access to all the Yocto Project development + branches and tag names used in the upstream repository.</para> + <para>The following transcript shows how to clone the Yocto Project Files' + Git repository into the current working directory. + <note>The name of the Yocto Project Files Git repository in the Yocto Project Files + Source Repositories is <filename>poky</filename>. + You can view the Yocto Project Source Repositories at + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink></note> + The command creates the local repository in a directory named <filename>poky</filename>. + For information on Git used within the Yocto Project, see the + "<link linkend='git'>Git</link>" section. + <literallayout class='monospaced'> $ git clone git://git.yoctoproject.org/poky Initialized empty Git repository in /home/scottrif/poky/.git/ remote: Counting objects: 116882, done. @@ -104,68 +114,78 @@ Receiving objects: 100% (116882/116882), 72.13 MiB | 2.68 MiB/s, done. Resolving deltas: 100% (80651/80651), done. </literallayout></para> <para>For another example of how to set up your own local Git repositories, see this - <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'> + <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'> wiki page</ulink>, which describes how to create both <filename>poky</filename> and <filename>meta-intel</filename> Git repositories.</para></listitem> </itemizedlist></para></listitem> <listitem id='local-kernel-files'><para><emphasis>Linux Yocto Kernel:</emphasis> If you are going to be making modifications to a supported Linux Yocto kernel, you need to establish local copies of the source. - This setup involves creating a bare clone of the Linux Yocto kernel and then cloning - that repository. + You can find Git repositories of supported Linux Yocto Kernels organized under + "Yocto Linux Kernel" in the Yocto Project Source Repositories at + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para> + <para>This setup involves creating a bare clone of the Linux Yocto kernel and then + copying that cloned repository. You can create the bare clone and the copy of the bare clone anywhere you like. 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>: + Doing so can speed up the process.</note></para> + <para>In the following example, the bare clone is named + <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 - build the kernel image. - In particular, it contains the kernel <filename>.bbappend</filename> files that you + The <filename>poky-extras</filename> Git repository contains metadata needed + only if you are modifying and building the kernel image. + In particular, it contains the kernel BitBake append (<filename>.bbappend</filename>) + files that you edit to point to your locally modified kernel source files and to build the kernel image. Pointing to these local files is much more efficient than requiring a download of the source files from upstream each time you make changes to the kernel.</para> - <para>It is good practice to create this Git repository inside the Yocto Project - files Git repository. - Following is an example that creates the <filename>poky-extras</filename> Git + <para>You can find the <filename>poky-extras</filename> Git Repository in the + "Yocto Metadata Layers" area of the Yocto Project Source Repositories at + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>. + It is good practice to create this Git repository inside the Yocto Project + files Git repository.</para> + <para>Following is an example that creates the <filename>poky-extras</filename> Git repository inside the Yocto Project files Git repository, which is named <filename>poky</filename> in this case: <literallayout class='monospaced'> - $ 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 with a local Git repository. + It is a good idea to use the same method used to set up the Yocto Project Files. Regardless of the method you use, the Yocto Project uses the following BSP layer naming scheme: <literallayout class='monospaced'> @@ -181,31 +201,33 @@ <itemizedlist> <listitem><para><emphasis>Tarball Extraction:</emphasis> You can download any released BSP tarball from the same - <ulink url='http://yoctoproject.org/download'>download site</ulink> used + <ulink url='&YOCTO_HOME_URL;/download'>download site</ulink> used to get the Yocto Project release. Once you have the tarball, just extract it into a directory of your choice. Again, this method just produces a snapshot of the BSP layer in the form of a hierarchical directory structure.</para></listitem> <listitem><para><emphasis>Git Repository Method:</emphasis> If you are working - with a Yocto Project files Git repository, you should also set up a - <filename>meta-intel</filename> Git repository. - Typically, you set up the <filename>meta-intel</filename> Git repository inside - the Yocto Project files Git repository.</para> - <para>For example, the following transcript shows the steps to clone the + with a Yocto Project Files Git repository, you should also use this method + to set up the <filename>meta-intel</filename> Git repository. + You can locate the <filename>meta-intel</filename> Git repository in the + "Yocto Metadata Layers" area of the Yocto Project Source Repositories at + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para> + <para>Typically, you set up the <filename>meta-intel</filename> Git repository inside + the Yocto Project Files Git repository. + For example, the following transcript shows the steps to clone the <filename>meta-intel</filename> Git repository inside the <filename>poky</filename> Git repository. <literallayout class='monospaced'> - $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'> + <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'> wiki page</ulink> referenced earlier covers how to set up the <filename>meta-intel</filename> Git repository.</para></listitem> </itemizedlist></para></listitem> @@ -213,7 +235,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='&YOCTO_DOCS_ADT_URL;#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 +248,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='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section in the Yocto Project Quick Start. </para> @@ -237,12 +259,20 @@ previous section.</para></listitem> <listitem><para>Initialize the build environment by sourcing a build environment script.</para></listitem> - <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file is set - up how you want it. - This file defines the target machine architecture and other build options.</para></listitem> - <listitem><para>Build the image using the BitBake command. - If you want information on Bitbake, see the user manual at - <ulink url='http://docs.openembedded.org/bitbake/html'></ulink>.</para></listitem> + <listitem><para>Optionally ensure the <filename>/conf/local.conf</filename> configuration file, + which is found in the Yocto Project build directory, + is set up how you want it. + This file defines many aspects of the build environment including + the target machine architecture through the + <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'>MACHINE</ulink></filename> variable, + the development machine's processor use through the + <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</ulink></filename> and + <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'>PARALLEL_MAKE</ulink></filename> variables, and + a centralized tarball download directory through the + <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'>DL_DIR</ulink></filename> variable.</para></listitem> + <listitem><para>Build the image using the <filename>bitbake</filename> command. + If you want information on BitBake, see the user manual at + <ulink url='&OE_DOCS_URL;/bitbake/html'></ulink>.</para></listitem> <listitem><para>Run the image either on the actual hardware or using the QEMU emulator.</para></listitem> </orderedlist> @@ -253,18 +283,37 @@ <title>Using Pre-Built Binaries and QEMU</title> <para> - Another option you have to get started is to use pre-built binaries. - This scenario is ideal for developing software applications to run on your target hardware. - To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and - then download the pre-built kernel that you will boot in the QEMU emulator. - Next, you must download and extract the target root filesystem for your target - machine’s architecture. - Finally, you set up the environment to emulate the hardware and then start the QEMU emulator. + Another option you have to get started is to use pre-built binaries. + The Yocto Project provides many types of binaries with each release. + See the <ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink> + section for descriptions of the types of binaries that ship with a Yocto Project + release. + </para> + + <para> + Using a pre-built binary is ideal for developing software applications to run on your + target hardware. + To do this, you need to be able to access the appropriate cross-toolchain tarball for + the architecture on which you are developing. + If you are using an SDK type image, the image ships with the complete toolchain native to + the architecture. + If you are not using an SDK type image, you need to separately download and + install the stand-alone Yocto Project cross-toolchain tarball. </para> <para> + Regardless of the type of image you are using, you need to download the pre-built kernel + that you will boot in the QEMU emulator and then download and extract the target root + filesystem for your target machine’s architecture. + You can get architecture-specific binaries and filesystem from + <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>. + You can get stand-alone toolchains from + <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchains</ulink>. + Once you have all your files, you set up the environment to emulate the hardware + by sourcing an environment setup script. + Finally, you start the QEMU emulator. 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='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>" section of the Yocto Project Quick Start. </para> </section> diff --git a/documentation/dev-manual/dev-manual.xml b/documentation/dev-manual/dev-manual.xml index 243afe4663..f2346f3c1a 100644 --- a/documentation/dev-manual/dev-manual.xml +++ b/documentation/dev-manual/dev-manual.xml @@ -1,5 +1,6 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <book id='dev-manual' lang='en' xmlns:xi="http://www.w3.org/2003/XInclude" @@ -33,10 +34,20 @@ <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> + <revision> + <revnumber>1.1.2</revnumber> + <date>July 2012</date> + <revremark>Released with the Yocto Project 1.1.2 Release.</revremark> + </revision> </revhistory> <copyright> - <year>2010-2011</year> + <year>©RIGHT_YEAR;</year> <holder>Linux Foundation</holder> </copyright> @@ -51,9 +62,9 @@ <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='&YOCTO_DOCS_DEV_URL;'> The Yocto Project Development Manual</ulink> on - the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website. + the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. For the latest version of this manual, see the manual on the website. </note> </legalnotice> diff --git a/documentation/dev-manual/figures/git-workflow.png b/documentation/dev-manual/figures/git-workflow.png Binary files differindex 12958c3fd9..4fdf42f89c 100644 --- a/documentation/dev-manual/figures/git-workflow.png +++ b/documentation/dev-manual/figures/git-workflow.png diff --git a/documentation/dev-manual/figures/index-downloads.png b/documentation/dev-manual/figures/index-downloads.png Binary files differindex 25102fab96..c907997db2 100644 --- a/documentation/dev-manual/figures/index-downloads.png +++ b/documentation/dev-manual/figures/index-downloads.png diff --git a/documentation/dev-manual/figures/kernel-example-repos-edison.png b/documentation/dev-manual/figures/kernel-example-repos-edison.png Binary files differnew file mode 100644 index 0000000000..f442be967d --- /dev/null +++ b/documentation/dev-manual/figures/kernel-example-repos-edison.png diff --git a/documentation/dev-manual/figures/kernel-example-repos.png b/documentation/dev-manual/figures/kernel-example-repos.png Binary files differdeleted file mode 100644 index 2449145550..0000000000 --- a/documentation/dev-manual/figures/kernel-example-repos.png +++ /dev/null diff --git a/documentation/dev-manual/figures/kernel-overview-3-edison.png b/documentation/dev-manual/figures/kernel-overview-3-edison.png Binary files differnew file mode 100644 index 0000000000..56d2e124d1 --- /dev/null +++ b/documentation/dev-manual/figures/kernel-overview-3-edison.png diff --git a/documentation/dev-manual/figures/kernel-overview-3.png b/documentation/dev-manual/figures/kernel-overview-3.png Binary files differdeleted file mode 100644 index e7637e5ba7..0000000000 --- a/documentation/dev-manual/figures/kernel-overview-3.png +++ /dev/null diff --git a/documentation/dev-manual/style.css b/documentation/dev-manual/style.css index 65b83e2220..da91d433a4 100644 --- a/documentation/dev-manual/style.css +++ b/documentation/dev-manual/style.css @@ -654,7 +654,7 @@ hr { .tip, .warning, .caution, .note { - border-color: #aaa; + border-color: #fff; } @@ -662,24 +662,24 @@ hr { .warning table th, .caution table th, .note table th { - border-bottom-color: #aaa; + border-bottom-color: #fff; } .warning { - background-color: #fea; + background-color: #f0f0f2; } .caution { - background-color: #fea; + background-color: #f0f0f2; } .tip { - background-color: #eff; + background-color: #f0f0f2; } .note { - background-color: #dfc; + background-color: #f0f0f2; } .glossary dl dt, @@ -946,8 +946,8 @@ table { .tip, .note { - background: #666666; - color: #fff; + background: #f0f0f2; + color: #333; padding: 20px; margin: 20px; } @@ -958,11 +958,26 @@ table { margin: 0em; font-size: 2em; font-weight: bold; - color: #fff; + color: #333; } .tip a, .note a { - color: #fff; + color: #333; text-decoration: underline; } + +.footnote { + font-size: small; + color: #333; +} + +/* Changes the announcement text */ +.tip h3, +.warning h3, +.caution h3, +.note h3 { + font-size:large; + color: #00557D; +} + diff --git a/documentation/kernel-manual/kernel-concepts.xml b/documentation/kernel-manual/kernel-concepts.xml index bcda78c4e1..4b3ee08408 100644 --- a/documentation/kernel-manual/kernel-concepts.xml +++ b/documentation/kernel-manual/kernel-concepts.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='kernel-concepts'> @@ -44,13 +45,13 @@ management techniques.</para></listitem> <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that the baseline kernel is the most stable official release.</para></listitem> - <listitem><para>Include major technological features as part of Yocto Project's up-rev - strategy.</para></listitem> + <listitem><para>Include major technological features as part of Yocto Project's + upward revision strategy.</para></listitem> <listitem><para>Present a kernel Git repository that, similar to the upstream <filename>kernel.org</filename> tree, has a clear and continuous history.</para></listitem> <listitem><para>Deliver a key set of supported kernel types, where each type is tailored - to a specific use case (e.g. networking, consumer, devices, and so forth).</para></listitem> + to meet a specific use (e.g. networking, consumer, devices, and so forth).</para></listitem> <listitem><para>Employ a Git branching strategy that, from a developer's point of view, results in a linear path from the baseline <filename>kernel.org</filename>, through a select group of features and @@ -78,7 +79,7 @@ </para> <para> This balance allows the team to deliver the most up-to-date kernel - as possible, while still ensuring that the team has a stable official release as + as possible, while still ensuring that the team has a stable official release for the baseline kernel version. </para> <para> @@ -94,8 +95,8 @@ </para> <para> Once a Yocto Project kernel is officially released, the Yocto Project team goes into - their next development cycle, or "uprev" cycle, while still continuing maintenance on the - released kernel. + their next development cycle, or upward revision (uprev) cycle, while still + continuing maintenance on the released kernel. It is important to note that the most sustainable and stable way to include feature development upstream is through a kernel uprev process. Back-porting hundreds of individual fixes and minor features from various @@ -148,7 +149,8 @@ <section id='architecture-overview'> <title>Overview</title> <para> - As mentioned earlier, a key goal of Yocto Project is to present the developer with + As mentioned earlier, a key goal of the Yocto Project is to present the + developer with a kernel that has a clear and continuous history that is visible to the user. The architecture and mechanisms used achieve that goal in a manner similar to the upstream <filename>kernel.org</filename>. @@ -159,9 +161,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 - Yocto Project Development Manual</ulink>. + "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" section in the + Yocto Project Development Manual. </para> <para> The result is that the user has the ability to see the added features and @@ -176,7 +177,7 @@ <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" /> </para> <para> - In the illustration, the "<filename>kernel.org</filename> Branch Point" + In the illustration, the "Kernel.org Branch Point" marks the specific spot (or release) from which the Yocto Project kernel is created. From this point "up" in the tree, features and differences are organized and tagged. @@ -288,11 +289,10 @@ <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 - Yocto Project Development Manual</ulink>. - This section overviews Git and describes a minimal set of commands that allow you to be - functional using Git. + "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" + section in the Yocto Project Development Manual. + These referenced sections overview Git and describe a minimal set of + commands that allow you to be functional using Git. <note> You can use as much, or as little, of what Git has to offer to accomplish what you need for your project. @@ -336,11 +336,6 @@ kernel toolkit: </itemizedlist> </para> --> </section> - - - - - </chapter> <!-- vim: expandtab tw=80 ts=4 diff --git a/documentation/kernel-manual/kernel-doc-intro.xml b/documentation/kernel-manual/kernel-doc-intro.xml index a9e51725da..c3fde6c731 100644 --- a/documentation/kernel-manual/kernel-doc-intro.xml +++ b/documentation/kernel-manual/kernel-doc-intro.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='kernel-doc-intro'> @@ -11,7 +12,7 @@ The Yocto Project presents the kernel as a fully patched, history-clean Git repository. The Git tree represents the selected features, board support, - and configurations extensively tested by Yocto Project. + and configurations extensively tested by the Yocto Project. The Yocto Project kernel allows the end user to leverage community best practices to seamlessly manage the development, build and debug cycles. </para> @@ -28,32 +29,39 @@ <listitem><para><emphasis>Using the Kernel:</emphasis> Describes best practices and "how-to" information that lets you put the kernel to practical use. - Some examples are "How to Build a - Project Specific Tree", "How to Examine Changes in a Branch", and "How to - Save Kernel Modifications."</para></listitem> + Some examples are how to examine changes in a branch and how to + save kernel modifications.</para></listitem> </itemizedlist> </para> <para> - For more information on the kernel, see the following links: + For more information on the Linux kernel, see the following links: <itemizedlist> - <listitem><para><ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem> - <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> - <listitem><para><ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> + <listitem><para>The Linux Foundation's guide for kernel development + process - <ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem> +<!-- <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> --> + <listitem><para>A fairly emcompassing guide on Linux kernel development - + <ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> </itemizedlist> </para> <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>. + For more discussion on the Yocto Project kernel, you can see these sections + in <ulink url='&YOCTO_DOCS_DEV_URL;'>The Yocto Project Development Manual</ulink>: + <itemizedlist> + <listitem><para> + "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-overview'>Kernel Overview</ulink>"</para></listitem> + <listitem><para> + "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-modification-workflow'>Kernel Modification Workflow</ulink>" + </para></listitem> + <listitem><para> + "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>"</para></listitem> + </itemizedlist> </para> <para> For general information on the Yocto Project, visit the website at - <ulink url='http://www.yoctoproject.org'></ulink>. + <ulink url='&YOCTO_HOME_URL;'></ulink>. </para> </section> diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml index df8605ed6f..79352d7418 100644 --- a/documentation/kernel-manual/kernel-how-to.xml +++ b/documentation/kernel-manual/kernel-how-to.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='kernel-how-to'> @@ -10,8 +11,8 @@ <title>Introduction</title> <para> This chapter describes how to accomplish tasks involving the kernel's tree structure. - This information is designed to help the developer that wants to modify the Yocto Project kernel - and contribute changes upstream to the Yocto Project. + The information is designed to help the developer that wants to modify the Yocto + Project kernel and contribute changes upstream to the Yocto Project. The information covers the following: <itemizedlist> <listitem><para>Tree construction</para></listitem> @@ -24,10 +25,11 @@ <section id='tree-construction'> <title>Tree Construction</title> <para> - This section describes construction of the Yocto Project kernel repositories as accomplished - by the Yocto Project team to create kernel repositories, which are found at - <ulink url='http://git.yoctoproject.org/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>, - that can be shipped as part of a Yocto Project release. + This section describes construction of the Yocto Project kernel repositories + as accomplished by the Yocto Project team to create kernel repositories. + These kernel repositories are found at + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink> + and can be shipped as part of a Yocto Project release. The team creates these repositories by compiling and executing the set of feature descriptions for every BSP/feature in the product. @@ -50,19 +52,25 @@ </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='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in The Yocto Project Development Manual. </para> <para> - Once the Git repository is set up on your local machine, you can switch to the - <filename>meta</filename> branch within the repository. - Here, you can see a snapshot of all the kernel configuration and feature descriptions that are - used to build the kernel repository. + Once you have cloned the kernel Git repository on your local machine, you can + switch to the <filename>meta</filename> branch within the repository. + Here is an example that assumes the local Git repository for the kernel is in + a top-level directory named <filename>linux-yocto-3.0</filename>: + <literallayout class='monospaced'> + $ cd ~/linux-yocto-3.0 + $ git checkout -b meta origin/meta + </literallayout> + Once you have checked out and switched to the <filename>meta</filename> branch, + you can see a snapshot of all the kernel configuration and feature descriptions that are + used to build that particular kernel repository. These descriptions are in the form of <filename>.scc</filename> files. </para> <para> - You should realize, however, that browsing your local snapshot of feature - descriptions and patches is not an effective way to determine what is in a + You should realize, however, that browsing your local kernel repository + for feature descriptions and patches is not an effective way to determine what is in a particular kernel branch. Instead, you should use Git directly to discover the changes in a branch. Using Git is an efficient and flexible way to inspect changes to the kernel. @@ -76,10 +84,12 @@ </note> </para> <para> - The following steps describe what happens when the Yocto kernel team constructs - the kernel tree given the introduction of a new top-level kernel feature or BSP. - These are the actions that effectively create the tree that includes the new feature, patch, - or BSP: + The following steps describe what happens when the Yocto Project Team constructs + the Yocto Linux kernel source Git repository (or tree) found at + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the + introduction of a new top-level kernel feature or BSP. + These are the actions that effectively create the tree + that includes the new feature, patch or BSP: <orderedlist> <listitem><para>A top-level kernel feature is passed to the kernel build subsystem. Normally, this feature is a BSP for a particular kernel type.</para></listitem> @@ -126,10 +136,11 @@ Any add-ons and configuration data are applied to the end of an existing branch. The full repository generation that is found in the official Yocto Project kernel repositories at - <ulink url='http://git.yoctoproject.org/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink> + <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink> is the combination of all supported boards and configurations.</para> <para>The technique the Yocto Project team uses is flexible and allows for seamless - blending of an immutable history with additional deployment specific patches. + blending of an immutable history with additional patches specific to a + deployment. Any additions to the kernel become an integrated part of the branches.</para> </note> </para> @@ -226,10 +237,8 @@ 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>" - section of - <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto - Project Development Manual</ulink>. + "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" + section of The Yocto Project Development Manual. </para> <section id='change-inspection-kernel-changes-commits'> @@ -244,8 +253,8 @@ In projects that have a collection of directories that contain patches to the kernel, it is possible to inspect or "grep" the contents of the directories to get a general feel for the changes. - This sort of patch inspection is not an efficient way to determine what has been done to the - kernel. + This sort of patch inspection is not an efficient way to determine what has been + done to the kernel. The reason it is inefficient is because there are many optional patches that are selected based on the kernel type and the feature description. Additionally, patches could exist in directories that are not included in the search. @@ -299,9 +308,11 @@ <title>Show a Particular Feature or Branch Change</title> <para> - Significant features or branches are tagged in the Yocto Project tree to divide - changes. - Remember to first determine (or add) the tag of interest. + Developers use tags in the Yocto Project tree to divide changes for significant + features or branches. + Once you know a particular tag, you can use Git commands + to show changes associated with the tag and find the branches that contain + the feature. <note> Because BSP branch, <filename>kernel.org</filename>, and feature tags are all present, there could be many tags. @@ -354,10 +365,10 @@ 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 - Yocto Project Development Manual</ulink>". + "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Pushing a Change + Upstream and Requesting a Pull</ulink>" and + "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-patch'>Submitting a Patch Through + Email</ulink>" sections in The Yocto Project Development Manual. </para> <para> @@ -624,8 +635,6 @@ For example, kernel patches should follow standards such as: <itemizedlist> <listitem><para> - <ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> - <listitem><para> <ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem> <listitem><para>Documentation/SubmittingPatches (in any linux kernel source tree)</para></listitem> @@ -637,9 +646,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 - Yocto Project Development Manual</ulink>". + "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a + Change</ulink>" section in The Yocto Project Development Manual. </para> <para> @@ -741,7 +749,8 @@ </para> <para> - The following commands illustrate how you can condense and merge two BSPs into a second SCM: + The following commands illustrate how you can condense and merge two BSPs into a + second SCM: <literallayout class='monospaced'> > git checkout yocto/standard/common-pc/base > git merge yocto/standard/common-pc-64/base @@ -772,10 +781,9 @@ 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 - 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> + the "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development + Example</ulink>" appendix in the Yocto Project Development Manual, or see the + <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink> wiki page. </para> @@ -792,7 +800,7 @@ your BSP easier. You can find all the BSPs that are supported and ship with the Yocto Project on the Yocto Project's Download page at - <ulink url='http://www.yoctoproject.org/download'></ulink>.</para></listitem> + <ulink url='&YOCTO_HOME_URL;/download'></ulink>.</para></listitem> <listitem><para><emphasis>Be sure you have the Base BSP:</emphasis> You need to either have the Yocto Project Git repository set up or download the tarball of the base BSP. diff --git a/documentation/kernel-manual/kernel-manual.xml b/documentation/kernel-manual/kernel-manual.xml index 214892f19c..14303e8286 100644 --- a/documentation/kernel-manual/kernel-manual.xml +++ b/documentation/kernel-manual/kernel-manual.xml @@ -1,5 +1,6 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <book id='kernel-manual' lang='en' xmlns:xi="http://www.w3.org/2003/XInclude" @@ -48,10 +49,20 @@ <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> + <revision> + <revnumber>1.1.2</revnumber> + <date>July 2012</date> + <revremark>Released with the Yocto Project 1.1.2 Release.</revremark> + </revision> </revhistory> <copyright> - <year>2010-2011</year> + <year>©RIGHT_YEAR;</year> <holder>Linux Foundation</holder> </copyright> @@ -63,9 +74,9 @@ <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='&YOCTO_DOCS_KERNEL_URL;'> The Yocto Project Kernel Architecture and Use Manual</ulink> on - the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website. + the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. For the latest version of this manual, see the manual on the website. </note> </legalnotice> diff --git a/documentation/kernel-manual/style.css b/documentation/kernel-manual/style.css index 33a01d125a..f919cca214 100644 --- a/documentation/kernel-manual/style.css +++ b/documentation/kernel-manual/style.css @@ -654,7 +654,7 @@ hr { .tip, .warning, .caution, .note { - border-color: #aaa; + border-color: #fff; } @@ -662,24 +662,24 @@ hr { .warning table th, .caution table th, .note table th { - border-bottom-color: #aaa; + border-bottom-color: #fff; } .warning { - background-color: #fea; + background-color: #f0f0f2; } .caution { - background-color: #fea; + background-color: #f0f0f2; } .tip { - background-color: #eff; + background-color: #f0f0f2; } .note { - background-color: #dfc; + background-color: #f0f0f2; } .glossary dl dt, @@ -946,8 +946,8 @@ table { .tip, .note { - background: #666666; - color: #fff; + background: #f0f0f2; + color: #333; padding: 20px; margin: 20px; } @@ -958,11 +958,26 @@ table { margin: 0em; font-size: 2em; font-weight: bold; - color: #fff; + color: #333; } .tip a, .note a { - color: #fff; + color: #333; text-decoration: underline; } + +.footnote { + font-size: small; + color: #333; +} + +/* Changes the announcement text */ +.tip h3, +.warning h3, +.caution h3, +.note h3 { + font-size:large; + color: #00557D; +} + diff --git a/documentation/poky-ref-manual/development.xml b/documentation/poky-ref-manual/development.xml index f18c055652..1fa31f005f 100644 --- a/documentation/poky-ref-manual/development.xml +++ b/documentation/poky-ref-manual/development.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id="platdev"> <title>Platform Development with the Yocto Project</title> @@ -82,7 +83,7 @@ The current release of the Yocto Project no longer supports the Anjuta plug-in. However, the Poky Anjuta Plug-in is available to download directly from the Poky Git repository located through the web interface at - <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins. + <ulink url="&YOCTO_GIT_URL;"></ulink> under IDE Plugins. The community is free to continue supporting it beyond the Yocto Project 0.9 Release. </note> @@ -91,10 +92,8 @@ 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'> - "Working Within Eclipse"</ulink> chapter in the - <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'> - "Application Development Toolkit (ADT) User's Guide."</ulink> + "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-eclipse'>Working Within Eclipse</ulink>" chapter in the + Yocto Project Application Development Toolkit (ADT) User's Guide. </para> </section> @@ -102,8 +101,8 @@ <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"> - Yocto Project Quick Start</ulink> in the "A Quick Test Run" section. + "<ulink url='&YOCTO_DOCS_ADT_URL;#test-run'>A Quick Test Run</ulink>" section of + the Yocto Project Quick Start. </para> <para> The QEMU images shipped with the Yocto Project contain complete toolchains @@ -162,8 +161,8 @@ <para> Working directly with the Yocto Project is a fast and effective development technique. The idea is that you can directly edit files in a working directory - (<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>) - or the source directory (<glossterm><link linkend='var-S'>S</link></glossterm>) + (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>) + or the source directory (<filename><link linkend='var-S'>S</link></filename>) and then force specific tasks to rerun in order to test the changes. An example session working on the matchbox-desktop package might look like this: @@ -203,16 +202,16 @@ <para> It is useful when making changes directly to the work directory files to do so using the Quilt tool as detailed in the - <link linkend='usingpoky-modifying-packages-quilt'> - Modifying Package Source Code with Quilt</link> section. + "<link linkend='usingpoky-modifying-packages-quilt'>Modifying Package Source Code with Quilt</link>" + section. Using Quilt, you can copy patches into the recipe directory and use the patches directly - through use of the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable. + through use of the <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> variable. </para> <para> For a review of the skills used in this section, see the - <link linkend="usingpoky-components-bitbake">BitBake</link> and - <link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> sections + "<link linkend="usingpoky-components-bitbake">BitBake</link>" and + "<link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link>" sections in this manual. </para> </section> @@ -231,7 +230,7 @@ still defined so you can use commands such as <filename>configure</filename> and <filename>make</filename>. The commands execute just as if the Yocto Project build system were executing them. - Consequently, workng this way can be helpful when debugging a build or preparing + Consequently, working this way can be helpful when debugging a build or preparing software to be used with the Yocto Project build system. </para> @@ -262,7 +261,7 @@ or <filename>compile</filename> commands as if they were being run by the Yocto Project build system itself. As noted earlier, the working directory also automatically changes to the - source directory (<glossterm><link linkend='var-S'>S</link></glossterm>). + source directory (<filename><link linkend='var-S'>S</link></filename>). </para> <para> @@ -272,8 +271,8 @@ <para> The default shell used by <filename>devshell</filename> is xterm. You can use other terminal forms by setting the - <glossterm><link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and - <glossterm><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables + <filename><link linkend='var-TERMCMD'>TERMCMD</link></filename> and + <filename><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></filename> variables in the Yocto Project's <filename>local.conf</filename> file found in the build directory. For examples of the other options available, see the "UI/Interaction Configuration" @@ -284,7 +283,7 @@ <para> Because an external shell is launched rather than opening directly into the - original terminal window, it allows easier interaction with Bitbake's multiple + original terminal window, it allows easier interaction with BitBake's multiple threads as well as accomodates a future client/server split. </para> @@ -294,7 +293,7 @@ instead of just using <filename>gcc</filename>. The same applies to other applications such as <filename>binutils</filename>, <filename>libtool</filename> and so forth. - The Yocto Project has setup environment variables such as <filename>CC</filename> + BitBake sets up environment variables such as <filename>CC</filename> to assist applications, such as <filename>make</filename> to find the correct tools.</para> <para>It is also worth noting that <filename>devshell</filename> still works over X11 forwarding and similar situations</para> @@ -333,7 +332,7 @@ It also allows you to perform post-mortem style analysis of program crashes. GDB is available as a package within the Yocto Project and by default is installed in sdk images. - See <xref linkend='ref-images'>Reference: Images</xref> for a description of these + See the "<link linkend='ref-images'>Reference: Images</link>" appendix for a description of these images. You can find information on GDB at <ulink url="http://sourceware.org/gdb/"/>. </para> @@ -671,7 +670,7 @@ <para> A graphical user interface for OProfile is also available. You can download and build this interface from the Yocto Project at - <ulink url="http://git.yoctoproject.org/cgit.cgi/oprofileui/"></ulink>. + <ulink url="&YOCTO_GIT_URL;/cgit.cgi/oprofileui/"></ulink>. If the "tools-profile" image feature is selected, all necessary binaries are installed onto the target device for OProfileUI interaction. </para> @@ -679,7 +678,7 @@ <para> Even though the Yocto Project usually includes all needed patches on the target device, you might find you need other OProfile patches for recent OProfileUI features. - If so, see the <ulink url='http://git.yoctoproject.org/cgit.cgi/oprofileui/tree/README'> + If so, see the <ulink url='&YOCTO_GIT_URL;/cgit.cgi/oprofileui/tree/README'> OProfileUI README</ulink> for the most recent information. </para> @@ -765,8 +764,8 @@ is not always necessary to actually have them on the device for OProfile use. All that is needed is a copy of the filesystem with the debug symbols present on the viewer system. - The <link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB - on the Host Computer</link> section covers how to create such a directory with + The "<link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB on the Host Computer</link>" + section covers how to create such a directory with the Yocto Project and how to use the OProfileUI Settings dialog to specify the location. If you specify the directory, it will be used when the file checksums match those on the system you are profiling. diff --git a/documentation/poky-ref-manual/extendpoky.xml b/documentation/poky-ref-manual/extendpoky.xml index 30fce1459f..234be80086 100644 --- a/documentation/poky-ref-manual/extendpoky.xml +++ b/documentation/poky-ref-manual/extendpoky.xml @@ -1,15 +1,17 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <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> @@ -23,7 +25,7 @@ variables. For information on variables that are useful for recipes and for information about recipe naming issues, see the - <link linkend='ref-varlocality-recipe-required'>Required</link> section for recipe variables. + "<link linkend='ref-varlocality-recipe-required'>Required</link>" section for recipe variables. </para> <para> @@ -113,7 +115,7 @@ <para> The variable <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link> </filename> is used to track source license changes as described in the - <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link> + "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>" section. You can quickly create Autotool-based recipes in a manner similar to the previous example. </para> @@ -531,10 +533,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='&YOCTO_DOCS_DEV_URL;#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'> - The Yocto Project Development Manual</ulink>. + The Yocto Project Development Manual. </para> <section id="platdev-newmachine-conffile"> @@ -658,324 +659,6 @@ </section> </section> - <section id="usingpoky-changes"> - <title>Making and Maintaining Changes</title> - <para> - Because the Yocto Project is extremely configurable and flexible, - we recognize that developers will want - to extend, configure or optimize it for their specific uses. - To best keep pace with future Yocto Project changes, - we recommend you make controlled changes to the Yocto Project. - </para> - - <para> - The Yocto Project supports a <link linkend='usingpoky-changes-layers'>"layers"</link> concept. - If you use layers properly, you can ease future upgrades and allow segregation - between the Yocto Project core and a given developer's changes. - The following section provides more advice on managing changes to the Yocto Project. - </para> - - <section id="usingpoky-changes-layers"> - <title>BitBake Layers</title> - <para> - Often, developers want to extend the Yocto Project either by adding packages - or by overriding files contained within the Yocto Project to add their own - functionality. - BitBake has a powerful mechanism called - "layers", which provides a way to handle this extension in a fully - supported and non-invasive fashion. - </para> - - <para> - The Yocto Project files include several additional layers such as - <filename>meta-rt</filename> and <filename>meta-yocto</filename> - that demonstrate this functionality. - The <filename>meta-rt</filename> layer is not enabled by default. - However, the <filename>meta-yocto</filename> layer is. - </para> - - <para> - To enable a layer, you simply add the layer's path to the - <filename><link linkend='var-BBLAYERS'>BBLAYERS</link></filename> variable in your - <filename>bblayers.conf</filename> file, which is found in the Yocto Project file's - build directory. - The following example shows how to enable the <filename>meta-rt</filename>: - <literallayout class='monospaced'> - LCONF_VERSION = "1" - - BBFILES ?= "" - BBLAYERS = " \ - /path/to/poky/meta \ - /path/to/poky/meta-yocto \ - /path/to/poky/meta-rt \ - " - </literallayout> - </para> - - <para> - BitBake parses each <filename>conf/layer.conf</filename> file for each layer in - <filename>BBLAYERS</filename> - and adds the recipes, classes and configurations contained within the layer to - the Yocto Project. - To create your own layer, independent of the Yocto Project files, - simply create a directory with a <filename>conf/layer.conf</filename> file and - add the directory to your <filename>bblayers.conf</filename> file. - </para> - - <para> - The <filename>meta-yocto/conf/layer.conf</filename> file demonstrates the - required syntax: - <literallayout class='monospaced'> - # We have a conf and classes directory, add to BBPATH - BBPATH := "${BBPATH}:${LAYERDIR}" - - # We have a packages directory, add to BBFILES - BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \ - ${LAYERDIR}/recipes-*/*/*.bbappend" - - BBFILE_COLLECTIONS += "yocto" - BBFILE_PATTERN_yocto := "^${LAYERDIR}/" - BBFILE_PRIORITY_yocto = "5" - </literallayout> - </para> - - <para> - In the previous example, the recipes for the layers are added to - <filename><link linkend='var-BBFILES'>BBFILES</link></filename>. - The <filename><link linkend='var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link></filename> - variable is then appended with the layer name. - The <filename><link linkend='var-BBFILE_PATTERN'>BBFILE_PATTERN</link></filename> variable - immediately expands with a regular expression used to match files from - <filename>BBFILES</filename> into - a particular layer, in this case by using the base pathname. - The <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename> variable - then assigns different priorities to the files in different layers. - Applying priorities is useful in situations where the same package might appear in multiple - layers and allows you to choose what layer should take precedence. - </para> - - <para> - Note the use of the <filename><link linkend='var-LAYERDIR'>LAYERDIR</link></filename> - variable with the immediate expansion operator. - The <filename>LAYERDIR</filename> variable expands to the directory of the current layer and - requires the immediate expansion operator so that BitBake does not wait to expand the variable - when it's parsing a different directory. - </para> - - <para> - BitBake can locate where other <filename>.bbclass</filename> and configuration files - are applied through the <filename>BBPATH</filename> environment variable. - For these cases, BitBake uses the first file with the matching name found in - <filename>BBPATH</filename>. - This is similar to the way the <filename>PATH</filename> variable is used for binaries. - We recommend, therefore, that you use unique <filename>.bbclass</filename> - and configuration file names in your custom layer. - </para> - - <para> - We also recommend the following: - <itemizedlist> - <listitem><para>Store custom layers in a Git repository that uses the - <filename>meta-prvt-XXXX</filename> format.</para></listitem> - <listitem><para>Clone the repository alongside other <filename>meta</filename> - directories in the Yocto Project source files area.</para></listitem> - </itemizedlist> - Following these recommendations keeps your Yocto Project files area and - its configuration entirely inside the Yocto Project's core base. - </para> - </section> - - <section id="usingpoky-changes-commits"> - <title>Committing Changes</title> - - <para> - Modifications to the Yocto Project are often managed under some kind of source - revision control system. - Because some simple practices can significantly improve usability, policy for committing changes - is important. - It helps to use a consistent documentation style when committing changes. - The Yocto Project development team has found the following practices work well: - <itemizedlist> - <listitem><para>The first line of the commit summarizes the change and begins with the - name of the affected package or packages. - However, not all changes apply to specific packages. - Consequently, the prefix could also be a machine name or class name.</para></listitem> - <listitem><para>The second part of the commit (if needed) is a longer more detailed - description of the changes. - Placing a blank line between the first and second parts helps with - readability.</para></listitem> - </itemizedlist> - </para> - - <para> - Following is an example commit: - <literallayout class='monospaced'> - bitbake/data.py: Add emit_func() and generate_dependencies() functions - - These functions allow generation of dependency data between functions and - variables allowing moves to be made towards generating checksums and allowing - use of the dependency information in other parts of BitBake. - - Signed-off-by: Richard Purdie richard.purdie@linuxfoundation.org - </literallayout> - </para> - - <para> - All commits should be self-contained such that they leave the - metadata in a consistent state that builds both before and after the - commit is made. - Besides being a good practice to follow, it helps ensure autobuilder test results - are valid. - </para> - </section> - - <section id="usingpoky-changes-prbump"> - <title>Package Revision Incrementing</title> - - <para> - If a committed change results in changing the package output, - then the value of the - <filename><link linkend='var-PR'>PR</link></filename> variable needs to be increased - (or "bumped") as part of that commit. - This means that for new recipes you must be sure to add the <filename>PR</filename> - variable and set its initial value equal to "r0". - Failing to define <filename>PR</filename> makes it easy to miss when you bump a package. - Note that you can only use integer values following the "r" in the - <filename>PR</filename> variable. - </para> - - <para> - If you are sharing a common <filename>.inc</filename> file with multiple recipes, - you can also use the - <filename><link linkend='var-INC_PR'>INC_PR</link></filename> variable to ensure that - the recipes sharing the <filename>.inc</filename> file are rebuilt when the - <filename>.inc</filename> file itself is changed. - The <filename>.inc</filename> file must set <filename>INC_PR</filename> - (initially to "r0"), and all recipes referring to it should set <filename>PR</filename> - to "$(INC_PR).0" initially, incrementing the last number when the recipe is changed. - If the <filename>.inc</filename> file is changed then its - <filename>INC_PR</filename> should be incremented. - </para> - - <para> - When upgrading the version of a package, assuming the - <filename><link linkend='var-PV'>PV</link></filename> changes, - the <filename>PR</filename> variable should be reset to "r0" - (or "$(INC_PR).0" if you are using <filename>INC_PR</filename>). - </para> - - <para> - Usually, version increases occur only to packages. - However, if for some reason <filename>PV</filename> changes but does not - increase, you can increase the - <filename><link linkend='var-PE'>PE</link></filename> variable (Package Epoch). - The <filename>PE</filename> variable defaults to "0". - </para> - - <para> - Version numbering strives to follow the - <ulink url='http://www.debian.org/doc/debian-policy/ch-controlfields.html'> - Debian Version Field Policy Guidelines</ulink>. - These guidelines define how versions are compared and what "increasing" a version means. - </para> - - <para> - There are two reasons for following the previously mentioned guidelines. - First, to ensure that when a developer updates and rebuilds, they get all the changes to - the repository and do not have to remember to rebuild any sections. - Second, to ensure that target users are able to upgrade their - devices using package manager commands such as <filename>opkg upgrade</filename> - (or similar commands for dpkg/apt or rpm-based systems). - </para> - - <para> - The goal is to ensure the Yocto Project has packages that can be upgraded in all cases. - </para> - </section> - - <section id="usingpoky-changes-collaborate"> - <title>Using The Yocto Project in a Team Environment</title> - - <para> - It might not be immediately clear how you can use the Yocto Project in a team environment, - or scale it for a large team of developers. - The specifics of any situation determine the best solution. - Granted that the Yocto Project offers immense flexibility regarding this, practices do exist - that experience has shown work well. - </para> - - <para> - The core component of any development effort with the Yocto Project is often an - automated build and testing framework along with an image generation process. - You can use these core components to check that the metadata can be built, - highlight when commits break the build, and provide up-to-date images that - allow developers to test the end result and use it as a base platform for further - development. - Experience shows that buildbot is a good fit for this role. - What works well is to configure buildbot to make two types of builds: - incremental and full (from scratch). - See <ulink url='http://www.yoctoproject.org:8010'>the buildbot for the - Yocto Project</ulink> for an example implementation that uses buildbot. - </para> - - <para> - You can tie incremental builds to a commit hook that triggers the build - each time a commit is made to the metadata. - This practice results in useful acid tests that determine whether a given commit - breaks the build in some serious way. - Associating a build to a commit can catch a lot of simple errors. - Furthermore, the tests are fast so developers can get quick feedback on changes. - </para> - - <para> - Full builds build and test everything from the ground up. - These types of builds usually happen at predetermined times like during the - night when the machine load is low. - </para> - - <para> - Most teams have many pieces of software undergoing active development at any given time. - You can derive large benefits by putting these pieces under the control of a source - control system that is compatible with the Yocto Project (i.e. Git or Subversion (SVN). - You can then set the autobuilder to pull the latest revisions of the packages - and test the latest commits by the builds. - This practice quickly highlights issues. - The Yocto Project easily supports testing configurations that use both a - stable known good revision and a floating revision. - The Yocto Project can also take just the changes from specific source control branches. - This capability allows you to track and test specific changes. - </para> - - <para> - Perhaps the hardest part of setting this up is defining the software project or - the Yocto Project metadata policies that surround the different source control systems. - Of course circumstances will be different in each case. - However, this situation reveals one of the Yocto Project's advantages - - the system itself does not - force any particular policy on users, unlike a lot of build systems. - The system allows the best policies to be chosen for the given circumstances. - </para> - </section> - - <section id="usingpoky-changes-updatingimages"> - <title>Updating Existing Images</title> - - <para> - Often, rather than re-flashing a new image, you might wish to install updated - packages into an existing running system. - You can do this by first sharing the <filename>tmp/deploy/ipk/</filename> directory - through a web server and then by changing <filename>/etc/opkg/base-feeds.conf</filename> - to point at the shared server. - Following is an example: - <literallayout class='monospaced'> - $ src/gz all http://www.mysite.com/somedir/deploy/ipk/all - $ src/gz armv7a http://www.mysite.com/somedir/deploy/ipk/armv7a - $ src/gz beagleboard http://www.mysite.com/somedir/deploy/ipk/beagleboard - </literallayout> - </para> - </section> - </section> - <section id="usingpoky-modifing-packages"> <title>Modifying Package Source Code</title> <para> @@ -1073,7 +756,7 @@ </section> <section id="building-multiple-architecture-libraries-into-one-image"> - <title>Combining Multiple versions of Library Files into One Image</title> + <title>Combining Multiple Versions of Library Files into One Image</title> <para> The build system offers the ability to build libraries with different @@ -1103,7 +786,7 @@ <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 + <ulink url='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki page. </para> @@ -1300,7 +983,7 @@ 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). + 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 @@ -1381,6 +1064,325 @@ file found in the Yocto Project files area. </para> </section> + + <section id="usingpoky-changes"> + <title>Making and Maintaining Changes</title> + <para> + Because the Yocto Project is extremely configurable and flexible, + we recognize that developers will want + to extend, configure or optimize it for their specific uses. + To best keep pace with future Yocto Project changes, + we recommend you make controlled changes to the Yocto Project. + </para> + + <para> + The Yocto Project supports a "<link linkend='usingpoky-changes-layers'>layers</link>" concept. + If you use layers properly, you can ease future upgrades and allow segregation + between the Yocto Project core and a given developer's changes. + The following section provides more advice on managing changes to the Yocto Project. + </para> + + <section id="usingpoky-changes-layers"> + <title>BitBake Layers</title> + <para> + Often, developers want to extend the Yocto Project either by adding packages + or by overriding files contained within the Yocto Project to add their own + functionality. + BitBake has a powerful mechanism called + "layers", which provides a way to handle this extension in a fully + supported and non-invasive fashion. + </para> + + <para> + The Yocto Project files include several additional layers such as + <filename>meta-rt</filename> and <filename>meta-yocto</filename> + that demonstrate this functionality. + The <filename>meta-rt</filename> layer is not enabled by default. + However, the <filename>meta-yocto</filename> layer is. + </para> + + <para> + To enable a layer, you simply add the layer's path to the + <filename><link linkend='var-BBLAYERS'>BBLAYERS</link></filename> variable in your + <filename>bblayers.conf</filename> file, which is found in the Yocto Project file's + build directory. + The following example shows how to enable the <filename>meta-rt</filename>: + <literallayout class='monospaced'> + LCONF_VERSION = "1" + + BBFILES ?= "" + BBLAYERS = " \ + /path/to/poky/meta \ + /path/to/poky/meta-yocto \ + /path/to/poky/meta-rt \ + " + </literallayout> + </para> + + <para> + BitBake parses each <filename>conf/layer.conf</filename> file for each layer in + <filename>BBLAYERS</filename> + and adds the recipes, classes and configurations contained within the layer to + the Yocto Project. + To create your own layer, independent of the Yocto Project files, + simply create a directory with a <filename>conf/layer.conf</filename> file and + add the directory to your <filename>bblayers.conf</filename> file. + </para> + + <para> + The <filename>meta-yocto/conf/layer.conf</filename> file demonstrates the + required syntax: + <literallayout class='monospaced'> + # We have a conf and classes directory, add to BBPATH + BBPATH := "${BBPATH}:${LAYERDIR}" + + # We have a packages directory, add to BBFILES + BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \ + ${LAYERDIR}/recipes-*/*/*.bbappend" + + BBFILE_COLLECTIONS += "yocto" + BBFILE_PATTERN_yocto := "^${LAYERDIR}/" + BBFILE_PRIORITY_yocto = "5" + </literallayout> + </para> + + <para> + In the previous example, the recipes for the layers are added to + <filename><link linkend='var-BBFILES'>BBFILES</link></filename>. + The <filename><link linkend='var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link></filename> + variable is then appended with the layer name. + The <filename><link linkend='var-BBFILE_PATTERN'>BBFILE_PATTERN</link></filename> variable + immediately expands with a regular expression used to match files from + <filename>BBFILES</filename> into + a particular layer, in this case by using the base pathname. + The <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename> variable + then assigns different priorities to the files in different layers. + Applying priorities is useful in situations where the same package might appear in multiple + layers and allows you to choose what layer should take precedence. + </para> + + <para> + Note the use of the <filename><link linkend='var-LAYERDIR'>LAYERDIR</link></filename> + variable with the immediate expansion operator. + The <filename>LAYERDIR</filename> variable expands to the directory of the current layer and + requires the immediate expansion operator so that BitBake does not wait to expand the variable + when it's parsing a different directory. + </para> + + <para> + BitBake can locate where other <filename>.bbclass</filename> and configuration files + are applied through the <filename>BBPATH</filename> environment variable. + For these cases, BitBake uses the first file with the matching name found in + <filename>BBPATH</filename>. + This is similar to the way the <filename>PATH</filename> variable is used for binaries. + We recommend, therefore, that you use unique <filename>.bbclass</filename> + and configuration file names in your custom layer. + </para> + + <para> + We also recommend the following: + <itemizedlist> + <listitem><para>Store custom layers in a Git repository that uses the + <filename>meta-prvt-XXXX</filename> format.</para></listitem> + <listitem><para>Clone the repository alongside other <filename>meta</filename> + directories in the Yocto Project source files area.</para></listitem> + </itemizedlist> + Following these recommendations keeps your Yocto Project files area and + its configuration entirely inside the Yocto Project's core base. + </para> + </section> + + <section id="usingpoky-changes-commits"> + <title>Committing Changes</title> + + <para> + Modifications to the Yocto Project are often managed under some kind of source + revision control system. + Because some simple practices can significantly improve usability, policy for committing changes + is important. + It helps to use a consistent documentation style when committing changes. + The Yocto Project development team has found the following practices work well: + <itemizedlist> + <listitem><para>The first line of the commit summarizes the change and begins with the + name of the affected package or packages. + However, not all changes apply to specific packages. + Consequently, the prefix could also be a machine name or class name.</para></listitem> + <listitem><para>The second part of the commit (if needed) is a longer more detailed + description of the changes. + Placing a blank line between the first and second parts helps with + readability.</para></listitem> + </itemizedlist> + </para> + + <para> + Following is an example commit: + <literallayout class='monospaced'> + bitbake/data.py: Add emit_func() and generate_dependencies() functions + + These functions allow generation of dependency data between functions and + variables allowing moves to be made towards generating checksums and allowing + use of the dependency information in other parts of BitBake. + + Signed-off-by: Richard Purdie richard.purdie@linuxfoundation.org + </literallayout> + </para> + + <para> + All commits should be self-contained such that they leave the + metadata in a consistent state that builds both before and after the + commit is made. + Besides being a good practice to follow, it helps ensure autobuilder test results + are valid. + </para> + </section> + + <section id="usingpoky-changes-prbump"> + <title>Package Revision Incrementing</title> + + <para> + If a committed change results in changing the package output, + then the value of the + <filename><link linkend='var-PR'>PR</link></filename> variable needs to be increased + (or "bumped") as part of that commit. + This means that for new recipes you must be sure to add the <filename>PR</filename> + variable and set its initial value equal to "r0". + Failing to define <filename>PR</filename> makes it easy to miss when you bump a package. + Note that you can only use integer values following the "r" in the + <filename>PR</filename> variable. + </para> + + <para> + If you are sharing a common <filename>.inc</filename> file with multiple recipes, + you can also use the + <filename><link linkend='var-INC_PR'>INC_PR</link></filename> variable to ensure that + the recipes sharing the <filename>.inc</filename> file are rebuilt when the + <filename>.inc</filename> file itself is changed. + The <filename>.inc</filename> file must set <filename>INC_PR</filename> + (initially to "r0"), and all recipes referring to it should set <filename>PR</filename> + to "$(INC_PR).0" initially, incrementing the last number when the recipe is changed. + If the <filename>.inc</filename> file is changed then its + <filename>INC_PR</filename> should be incremented. + </para> + + <para> + When upgrading the version of a package, assuming the + <filename><link linkend='var-PV'>PV</link></filename> changes, + the <filename>PR</filename> variable should be reset to "r0" + (or "$(INC_PR).0" if you are using <filename>INC_PR</filename>). + </para> + + <para> + Usually, version increases occur only to packages. + However, if for some reason <filename>PV</filename> changes but does not + increase, you can increase the + <filename><link linkend='var-PE'>PE</link></filename> variable (Package Epoch). + The <filename>PE</filename> variable defaults to "0". + </para> + + <para> + Version numbering strives to follow the + <ulink url='http://www.debian.org/doc/debian-policy/ch-controlfields.html'> + Debian Version Field Policy Guidelines</ulink>. + These guidelines define how versions are compared and what "increasing" a version means. + </para> + + <para> + There are two reasons for following the previously mentioned guidelines. + First, to ensure that when a developer updates and rebuilds, they get all the changes to + the repository and do not have to remember to rebuild any sections. + Second, to ensure that target users are able to upgrade their + devices using package manager commands such as <filename>opkg upgrade</filename> + (or similar commands for dpkg/apt or rpm-based systems). + </para> + + <para> + The goal is to ensure the Yocto Project has packages that can be upgraded in all cases. + </para> + </section> + + <section id="usingpoky-changes-collaborate"> + <title>Using The Yocto Project in a Team Environment</title> + + <para> + It might not be immediately clear how you can use the Yocto Project in a team environment, + or scale it for a large team of developers. + The specifics of any situation determine the best solution. + Granted that the Yocto Project offers immense flexibility regarding this, practices do exist + that experience has shown work well. + </para> + + <para> + The core component of any development effort with the Yocto Project is often an + automated build and testing framework along with an image generation process. + You can use these core components to check that the metadata can be built, + highlight when commits break the build, and provide up-to-date images that + allow developers to test the end result and use it as a base platform for further + development. + Experience shows that buildbot is a good fit for this role. + What works well is to configure buildbot to make two types of builds: + incremental and full (from scratch). + See <ulink url='&YOCTO_AB_URL;:8010'>the buildbot for the + Yocto Project</ulink> for an example implementation that uses buildbot. + </para> + + <para> + You can tie incremental builds to a commit hook that triggers the build + each time a commit is made to the metadata. + This practice results in useful acid tests that determine whether a given commit + breaks the build in some serious way. + Associating a build to a commit can catch a lot of simple errors. + Furthermore, the tests are fast so developers can get quick feedback on changes. + </para> + + <para> + Full builds build and test everything from the ground up. + These types of builds usually happen at predetermined times like during the + night when the machine load is low. + </para> + + <para> + Most teams have many pieces of software undergoing active development at any given time. + You can derive large benefits by putting these pieces under the control of a source + control system that is compatible with the Yocto Project (i.e. Git or Subversion (SVN). + You can then set the autobuilder to pull the latest revisions of the packages + and test the latest commits by the builds. + This practice quickly highlights issues. + The Yocto Project easily supports testing configurations that use both a + stable known good revision and a floating revision. + The Yocto Project can also take just the changes from specific source control branches. + This capability allows you to track and test specific changes. + </para> + + <para> + Perhaps the hardest part of setting this up is defining the software project or + the Yocto Project metadata policies that surround the different source control systems. + Of course circumstances will be different in each case. + However, this situation reveals one of the Yocto Project's advantages - + the system itself does not + force any particular policy on users, unlike a lot of build systems. + The system allows the best policies to be chosen for the given circumstances. + </para> + </section> + + <section id="usingpoky-changes-updatingimages"> + <title>Updating Existing Images</title> + + <para> + Often, rather than re-flashing a new image, you might wish to install updated + packages into an existing running system. + You can do this by first sharing the <filename>tmp/deploy/ipk/</filename> directory + through a web server and then by changing <filename>/etc/opkg/base-feeds.conf</filename> + to point at the shared server. + Following is an example: + <literallayout class='monospaced'> + $ src/gz all http://www.mysite.com/somedir/deploy/ipk/all + $ src/gz armv7a http://www.mysite.com/somedir/deploy/ipk/armv7a + $ src/gz beagleboard http://www.mysite.com/somedir/deploy/ipk/beagleboard + </literallayout> + </para> + </section> + </section> + </chapter> <!-- diff --git a/documentation/poky-ref-manual/faq.xml b/documentation/poky-ref-manual/faq.xml index 35ac845731..61853b5120 100644 --- a/documentation/poky-ref-manual/faq.xml +++ b/documentation/poky-ref-manual/faq.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='faq'> <title>FAQ</title> @@ -7,13 +8,13 @@ <qandaentry> <question> <para> - How does Poky differ from <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>? + How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>? </para> </question> <answer> <para> Poky is the Yocto Project build system that was derived from <ulink - url='http://www.openembedded.org/'>OpenEmbedded</ulink>. + url='&OE_HOME_URL;'>OpenEmbedded</ulink>. Poky is a stable, smaller subset focused on the mobile environment. Development in the Yocto Project using Poky is closely tied to OpenEmbedded with features being merged regularly between the two for mutual benefit. @@ -33,8 +34,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='&YOCTO_PYTHON-i686_DL_URL;'>32-bit tarball</ulink></para></listitem> + <listitem><para><ulink url='&YOCTO_PYTHON-x86_64_DL_URL;'>64-bit tarball</ulink></para></listitem> </itemizedlist> </para> <para> @@ -139,7 +140,7 @@ <para> To add a package, you need to create a BitBake recipe. For information on how to add a package, see the - <link linkend='usingpoky-extend-addpkg'>Adding a Package</link> section + "<link linkend='usingpoky-extend-addpkg'>Adding a Package</link>" section earlier in this manual. </para> </answer> @@ -171,7 +172,7 @@ </question> <answer> <para> - <ulink url='http://www.gnome.org/mobile/'>GNOME Mobile</ulink> is a subset of the GNOME + GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink> platform targeted at mobile and embedded devices. The the main difference between GNOME Mobile and standard GNOME is that desktop-orientated libraries have been removed, along with deprecated libraries, @@ -385,9 +386,9 @@ </question> <answer> <para> - You need to create a form factor file as described in - <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref> - and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows: + You need to create a form factor file as described in the + "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>" + section and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows: <literallayout class='monospaced'> HAVE_TOUCHSCREEN=1 </literallayout> @@ -407,8 +408,8 @@ automatically bring up network interfaces. Therefore, you will need to add a BSP-specific netbase that includes an interfaces file. - See <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref> - for information on creating these types of miscellaneous recipe files. + See the "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>" + section for information on creating these types of miscellaneous recipe files. </para> <para> For example, add the following files to your layer: @@ -493,8 +494,8 @@ <qandaentry> <question> - <para> - How does the Yocto Project obtain source code and will it work behind my + <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'> + How does the Yocto Project build system obtain source code and will it work behind my firewall or proxy server? </para> </question> @@ -573,7 +574,7 @@ any network accesses to anything other than the PREMIRROR would fail. </para> <para> - Poky also honors the standard environment variables + Poky also honors the standard shell environment variables <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, <filename>https_proxy</filename>, and <filename>all_proxy</filename> to redirect requests through proxy servers. diff --git a/documentation/poky-ref-manual/introduction.xml b/documentation/poky-ref-manual/introduction.xml index e2d49cdb99..eaf1efbc1e 100644 --- a/documentation/poky-ref-manual/introduction.xml +++ b/documentation/poky-ref-manual/introduction.xml @@ -1,5 +1,6 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <chapter id='intro'> <title>Introduction</title> @@ -15,10 +16,13 @@ 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='&YOCTO_DOCS_QS_URL;'> Yocto Project Quick Start</ulink>. + For task-based information using the Yocto Project, see + <ulink url='&YOCTO_DOCS_DEV_URL;'> + 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>. + <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>. </para> </section> @@ -37,6 +41,11 @@ 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 the click-through licensing scheme.</para></listitem> @@ -89,11 +98,9 @@ <section id='intro-requirements'> <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'> - 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'> - Yocto Project Quick Start</ulink>. + For Yocto Project system requirements, see the + <ulink url='&YOCTO_DOCS_QS_URL;#resources'> + What You Need and How You Get It</ulink> section in the Yocto Project Quick Start. </para> </section> @@ -104,14 +111,14 @@ 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='&YOCTO_DL_URL;/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 experimental builds.</para></listitem> <listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases of the Yocto Project and supported BSPs at the - <ulink url='http://www.yoctoproject.org'>Yocto Project website</ulink>. + <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>. Along with these downloads, you can find lots of other information at this site. </para></listitem> </itemizedlist> @@ -124,11 +131,9 @@ Development using the Yocto Project requires a local copy of the Yocto Project files. 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'> - Getting Setup</ulink> section in - <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'> - The Yocto Project Development Manual</ulink>. + For information on both these methods, see the + "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>" + section in The Yocto Project Development Manual. </para> </section> diff --git a/documentation/poky-ref-manual/poky-ref-manual.xml b/documentation/poky-ref-manual/poky-ref-manual.xml index 37059096e3..f2fd81645e 100644 --- a/documentation/poky-ref-manual/poky-ref-manual.xml +++ b/documentation/poky-ref-manual/poky-ref-manual.xml @@ -1,5 +1,6 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <book id='poky-ref-manual' lang='en' xmlns:xi="http://www.w3.org/2003/XInclude" @@ -62,10 +63,20 @@ <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> + <revision> + <revnumber>1.1.2</revnumber> + <date>July 2012</date> + <revremark>Released with the Yocto Project 1.1.2 Release.</revremark> + </revision> </revhistory> <copyright> - <year>2007-2011</year> + <year>©RIGHT_YEAR;</year> <holder>Linux Foundation</holder> </copyright> @@ -77,9 +88,9 @@ <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='&YOCTO_DOCS_REF_URL;'> The Yocto Project Reference Manual</ulink> on - the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website. + the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. For the latest version of this manual, see the manual on the website. </note> </legalnotice> @@ -92,6 +103,8 @@ <xi:include href="extendpoky.xml"/> + <xi:include href="technical-details.xml"/> + <xi:include href="../bsp-guide/bsp.xml"/> <xi:include href="development.xml"/> diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml index 6851fbf603..8f0023cf1d 100644 --- a/documentation/poky-ref-manual/ref-bitbake.xml +++ b/documentation/poky-ref-manual/ref-bitbake.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='ref-bitbake'> @@ -35,7 +36,7 @@ The first thing BitBake does is look for the <filename>bitbake.conf</filename> file. The Yocto Project keeps this file in the Yocto Project file's <filename>meta/conf/</filename> directory. - BitBake finds it by examining the <filename>BBPATH</filename> environment + BitBake finds it by examining its <filename>BBPATH</filename> environment variable and looking for the <filename>meta/conf/</filename> directory. </para> @@ -53,7 +54,7 @@ and the machine configuration file (set by the <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable). - The <filename>DISTRO</filename> and <filename>MACHINE</filename> environment + The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment variables are both usually set in the <filename>local.conf</filename> file. Valid distribution @@ -86,7 +87,7 @@ <filename>meta/recipes-*/</filename> directory within Poky. Adding extra content to <filename>BBFILES</filename> is best achieved through the use of BitBake layers as described in the - <link linkend='usingpoky-changes-layers'>BitBake Layers</link> section. + "<link linkend='usingpoky-changes-layers'>BitBake Layers</link>" section. </para> <para> @@ -207,17 +208,16 @@ 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'> - Building an Image</ulink> section in the - <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'> - Yocto Project Quick Start</ulink> for more information. + "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" + section in the Yocto Project Quick Start for more information. </para> <para> As each task completes, a timestamp is written to the directory specified by the <filename><link linkend='var-STAMPS'>STAMPS</link></filename> variable (usually <filename>build/tmp/stamps/*/</filename>). - On subsequent runs, BitBake looks at the <filename>STAMPS</filename> directory and does not rerun + On subsequent runs, BitBake looks at the <filename>/build/tmp/stamps</filename> + directory and does not rerun tasks that are already completed unless a timestamp is found to be invalid. Currently, invalid timestamps are only considered on a per <filename>.bb</filename> file basis. @@ -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 the "<link linkend='checksums'>Checksums (Signatures)</link>" section. + </note> + </section> <section id='ref-bitbake-commandline'> <title>BitBake Command Line</title> @@ -359,8 +401,8 @@ Options: This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename> variable. See the - <link linkend='platdev-appdev-srcrev'>Development Within Yocto Project for a Package that Uses - an External SCM</link> section for more information. + "<link linkend='platdev-appdev-srcrev'>Development Within Yocto Project for a Package that Uses + an External SCM</link>" section for more information. </para> </section> diff --git a/documentation/poky-ref-manual/ref-classes.xml b/documentation/poky-ref-manual/ref-classes.xml index 1532ccc917..78a081f461 100644 --- a/documentation/poky-ref-manual/ref-classes.xml +++ b/documentation/poky-ref-manual/ref-classes.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='ref-classes'> <title>Reference: Classes</title> @@ -49,7 +50,7 @@ This class defines a set of tasks (configure, compile etc.) that work for all Autotooled packages. It should usually be enough to define a few standard variables as documented in the - <link linkend='usingpoky-extend-addpkg-autotools'>Autotooled Package</link> section + "<link linkend='usingpoky-extend-addpkg-autotools'>Autotooled Package</link>" section and then simply <filename>inherit autotools</filename>. This class can also work with software that emulates Autotools. </para> @@ -139,7 +140,7 @@ </para> <para> - During staging, Bitbake installs such scripts into the + During staging, BitBake installs such scripts into the <filename>sysroots/</filename> directory. BitBake also changes all paths to point into the <filename>sysroots/</filename> directory so all builds that use the script will use the correct @@ -166,7 +167,7 @@ </para> <para> - During staging, Bitbake installs <filename>pkg-config</filename> data into the + During staging, BitBake installs <filename>pkg-config</filename> data into the <filename>sysroots/</filename> directory. By making use of sysroot functionality within <filename>pkg-config</filename>, this class no longer has to manipulate the files. @@ -252,8 +253,8 @@ <para> This class adds the <filename>devshell</filename> task. Distribution policy dictates whether to include this class as the Yocto Project does. - See the <link - linkend='platdev-appdev-devshell'>Development Within a Development Shell</link> section + See the + "<link linkend='platdev-appdev-devshell'>Development Within a Development Shell</link>" section for more information about using devshell. </para> </section> @@ -313,9 +314,9 @@ You can find additional information on the effects of the package class at these two Yocto Project mailing list links: <itemizedlist> - <listitem><para><ulink url='https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html'> + <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html'> https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</ulink></para></listitem> - <listitem><para><ulink url='https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html'> + <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html'> https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</ulink></para></listitem> </itemizedlist> </para> @@ -391,6 +392,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'> diff --git a/documentation/poky-ref-manual/ref-features.xml b/documentation/poky-ref-manual/ref-features.xml index 6b3e5c241e..c61b985f8a 100644 --- a/documentation/poky-ref-manual/ref-features.xml +++ b/documentation/poky-ref-manual/ref-features.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='ref-features'> <title>Reference: Features</title> diff --git a/documentation/poky-ref-manual/ref-images.xml b/documentation/poky-ref-manual/ref-images.xml index 4e7b029ea7..ae45437a6b 100644 --- a/documentation/poky-ref-manual/ref-images.xml +++ b/documentation/poky-ref-manual/ref-images.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='ref-images'> <title>Reference: Images</title> @@ -45,7 +46,10 @@ <listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis> A small image just capable of allowing a device to boot.</para></listitem> <listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis> - A <filename>core-image-minimal</filename> image suitable for development work. + A <filename>core-image-minimal</filename> image suitable for development work + using the host. + The image includes headers and libraries you can use in a host development + environment. </para></listitem> <listitem><para><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis> A <filename>core-image-minimal</filename> image that has the Minimal RAM-based @@ -64,13 +68,17 @@ A <filename>core-image-basic</filename> image suitable for implementations that conform to Linux Standard Base (LSB).</para></listitem> <listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis> - A <filename>core-image-lsb</filename> image that is suitable for development work. + A <filename>core-image-lsb</filename> image that is suitable for development work + using the host. + The image includes headers and libraries you can use in a host development + environment. </para></listitem> <listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis> A <filename>core-image-lsb</filename> that includes everything in meta-toolchain - but also includes development headers and libraries to form a complete standalone SDK. - See the <link linkend='platdev-appdev-external-sdk'> - External Development Using the Poky SDK</link> section for more information. + but also includes development headers and libraries to form a complete standalone SDK. + This image is suitable for development using the target. + See the "<link linkend='platdev-appdev-external-sdk'> + External Development Using the Poky SDK</link>" section for more information. </para></listitem> <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis> An image with support for the Open GL-based toolkit Clutter, which enables development of @@ -81,16 +89,17 @@ The image supports X11 with a Sato theme and Pimlico applications and also contains terminal, editor, and file manager.</para></listitem> <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis> - A <filename>core-image-sato</filename> image suitable for development - that also includes a native toolchain and libraries needed to build applications on - the device itself. - The image also includes testing and profiling tools as well as debug symbols. + A <filename>core-image-sato</filename> image suitable for development + using the host. + The image includes libraries needed to build applications on the device itself, + testing and profiling tools, and debug symbols. This image was formerly <filename>core-image-sdk</filename>.</para></listitem> <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis> A <filename>core-image-sato</filename> image that includes everything in meta-toolchain. - The image also includes development headers and libraries to form a complete standalone SDK. - See the <link linkend='platdev-appdev-external-sdk'> - External Development Using the Poky SDK</link> section for more information. + The image also includes development headers and libraries to form a complete standalone SDK + and is suitable for development using the target. + See the "<link linkend='platdev-appdev-external-sdk'> + External Development Using the Poky SDK</link>" section for more information. </para></listitem> </itemizedlist> diff --git a/documentation/poky-ref-manual/ref-structure.xml b/documentation/poky-ref-manual/ref-structure.xml index 63659c8cbf..176c42fe8d 100644 --- a/documentation/poky-ref-manual/ref-structure.xml +++ b/documentation/poky-ref-manual/ref-structure.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='ref-structure'> @@ -14,10 +15,8 @@ <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'> - Getting Setup</ulink> section in the - <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'> - The Yocto Project Development Manual</ulink>. + "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>" + section in the Yocto Project Development Manual. </para> <section id='structure-core'> @@ -35,7 +34,7 @@ from BitBake itself. Consequently, most users do not need to worry about BitBake. The <filename>bitbake/bin/</filename> directory is placed - into the <filename>PATH</filename> environment variable by the + into the shell's <filename>PATH</filename> environment variable by the <link linkend="structure-core-script">oe-init-build-env</link> script. </para> @@ -121,7 +120,7 @@ This directory contains various integration scripts that implement extra functionality in the Yocto Project environment (e.g. QEMU scripts). The <link linkend="structure-core-script">oe-init-build-env</link> script appends this - directory to the <filename>PATH</filename> environment variable. + directory to the shell's <filename>PATH</filename> environment variable. </para> <para> @@ -363,7 +362,7 @@ <para> This directory contains intermediate packaging data that is used later in the packaging process. - For more information, see <link linkend='ref-classes-package'>package.bbclass</link>. + For more information, see the "<link linkend='ref-classes-package'>Packaging - package*.bbclass</link>" section. </para> </section> @@ -388,8 +387,8 @@ referred to as <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created. Within this directory, the source is unpacked to <filename>linux-qemux86-standard-build</filename> and then patched by Quilt - (see the <link linkend="usingpoky-modifying-packages-quilt">Modifying Package Source Code - With Quilt</link> section). + (see the "<link linkend="usingpoky-modifying-packages-quilt">Modifying Package Source Code + With Quilt</link>" section). Within the <filename>linux-qemux86-standard-build</filename> directory, standard Quilt directories <filename>linux-3.0/patches</filename> and <filename>linux-3.0/.pc</filename> are created, @@ -480,8 +479,8 @@ <title><filename>meta/recipes-bsp/</filename></title> <para> - This directory contains anything linking to specific hardware or hardware configuration information - such as "u-boot" and "grub". + This directory contains anything linking to specific hardware or hardware + configuration information such as "u-boot" and "grub". </para> </section> diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml index 6843094fca..cc4a87447a 100644 --- a/documentation/poky-ref-manual/ref-variables.xml +++ b/documentation/poky-ref-manual/ref-variables.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <!-- Dummy chapter --> <appendix id='ref-variables-glos'> @@ -75,7 +76,7 @@ <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm> <glossdef> <para>The maximum number of tasks BitBake should run in parallel at any one time. - If your host development system supports mulitiple cores a good rule of thumb + If your host development system supports multiple cores, a good rule of thumb is to set this variable to twice the number of cores.</para> </glossdef> </glossentry> @@ -285,6 +286,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> @@ -305,8 +307,8 @@ <glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm> <glossdef> <para>Alias names used for the recipe in various Linux distributions.</para> - <para>See <link linkend='usingpoky-configuring-DISTRO_PN_ALIAS'> - Handling a Package Name Alias</link> section for more information.</para> + <para>See "<link linkend='usingpoky-configuring-DISTRO_PN_ALIAS'> + Handling a Package Name Alias</link>" section for more information.</para> </glossdef> </glossentry> @@ -328,6 +330,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> @@ -444,7 +447,7 @@ The options to pass in <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename> and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename> - when compiling an optimised system. + when compiling an optimized system. This variable defaults to "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2". </para> @@ -474,7 +477,7 @@ Typically, you configure this variable in image recipes. Note that you can add extra features to the image by using the <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable. - See the <link linkend="ref-features-image">Reference: Images</link> section for the + See the "<link linkend="ref-features-image">Reference: Images</link>" section for the list of features present in images built by the Yocto Project.</para> </glossdef> </glossentry> @@ -676,8 +679,8 @@ This variable must be defined for all recipes (unless <filename>LICENSE</filename> is set to "CLOSED")</para> <para>For more information, see the - <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'> - Track License Change</link> section</para> + "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>" + section</para> </glossdef> </glossentry> @@ -693,6 +696,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. @@ -704,7 +708,7 @@ </para> <para> This variable is similar to the - <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link> + <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename> variable with the exception that the package being built has a build dependency on the variable's list of packages. In other words, the image will not build if a file in this list is not found. @@ -722,6 +726,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. @@ -733,7 +738,7 @@ </para> <para> This variable is similar to the - <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link> + <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link></filename> variable with the exception that the package being built does not have a build dependency on the variable's list of packages. In other words, the image will build if a file in this list is not found. @@ -781,7 +786,7 @@ </para> <para> This variable is similar to the - <link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link> + <filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></filename> variable with the exception that the package being built has a build dependency on the variable's list of packages. In other words, the image will not build if a file in this list is not found. @@ -805,6 +810,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. @@ -817,7 +823,7 @@ </para> <para> This variable is similar to the - <link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link> + <filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></filename> variable with the exception that the package being built does not have a build dependency on the variable's list of packages. In other words, the image will build if a file in this list is not found. @@ -843,7 +849,7 @@ <glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm> <glossdef> <para>Specifies the list of device features. - See the <link linkend='ref-features-machine'>Machine</link> section for + See the "<link linkend='ref-features-machine'>Machine</link>" section for more information.</para> </glossdef> </glossentry> @@ -881,7 +887,7 @@ </literallayout> For information on build performance effects as a result of the package manager use, see - <link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link> + "<link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>" in this manual. </para> </glossdef> @@ -927,7 +933,7 @@ This variable is usually in the form <filename>-j 4</filename>, where the number represents the maximum number of parallel threads make can run. If you development host supports multiple cores a good rule of thumb is to set - this variable to one and a half times the number of cores on the host.</para> + this variable to twice the number of cores on the host.</para> </glossdef> </glossentry> @@ -1112,7 +1118,7 @@ The package being built does not depend on this list of packages in order to successfully build, but needs them for the extended usability. To specify runtime dependencies for packages, see the - <link linkend='var-RDEPENDS'>RDEPENDS</link> variable. + <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variable. </para> <para> The Yocto Project build process automatically installs the list of packages @@ -1155,7 +1161,7 @@ <para> The path to unpacked sources. By default, this path is - "${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}". + "<filename>${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}</filename>". </para> </glossdef> </glossentry> @@ -1230,13 +1236,14 @@ <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> contains files that are machine-specific. If so, the Yocto Project automatically changes <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>. - Setting this variable to "0" disables this behaviour. + Setting this variable to "0" disables this behavior. </para> </glossdef> </glossentry> diff --git a/documentation/poky-ref-manual/ref-varlocality.xml b/documentation/poky-ref-manual/ref-varlocality.xml index 0a2477c123..22a97a00be 100644 --- a/documentation/poky-ref-manual/ref-varlocality.xml +++ b/documentation/poky-ref-manual/ref-varlocality.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='ref-varlocality'> <title>Reference: Variable Context</title> diff --git a/documentation/poky-ref-manual/resources.xml b/documentation/poky-ref-manual/resources.xml index a5ce60b408..5dc6153bcb 100644 --- a/documentation/poky-ref-manual/resources.xml +++ b/documentation/poky-ref-manual/resources.xml @@ -1,5 +1,6 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <appendix id='resources'> <title>Contributing to the Yocto Project</title> @@ -10,10 +11,8 @@ 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'> - Yocto Project Release</ulink> list item in - <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto - Project Development Manual</ulink>. + see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>" + list item in the Yocto Project Development Manual. </para> </section> @@ -22,7 +21,7 @@ <para> If you find problems with the Yocto Project, you should report them using the - Bugzilla application at <ulink url='http://bugzilla.yoctoproject.org/'></ulink>. + Bugzilla application at <ulink url='&YOCTO_BUGZILLA_URL;'></ulink>. </para> </section> @@ -33,13 +32,13 @@ To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions: <itemizedlist> <listitem><para><emphasis> - <ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink></emphasis>: + <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink></emphasis>: Use this list to receive offical Yocto Project announcements for developments and to learn about Yocto Project milestones.</para></listitem> - <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink></emphasis>: + <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink></emphasis>: Use this list to monitor Yocto Project development discussions, ask questions, and get help.</para></listitem> - <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink></emphasis>: + <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink></emphasis>: Use this list to monitor discussions about the Yocto Project build system Poky, ask questions, and get help.</para></listitem> </itemizedlist> @@ -50,7 +49,7 @@ <title>Internet Relay Chat (IRC)</title> <para> - Two IRC channels on freenode are available for Yocto Project and Poky discussions: + Two IRC channels on freenode are available for the Yocto Project and Poky discussions: <itemizedlist> <listitem><para><filename>#yocto</filename></para></listitem> <listitem><para><filename>#poky</filename></para></listitem> @@ -64,19 +63,19 @@ <para> Following is a list of resources you will find helpful: <itemizedlist> - <listitem><para><emphasis><ulink url='http://yoctoproject.org'>The Yocto Project website</ulink>: + <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>: </emphasis> The home site for the Yocto Project.</para></listitem> - <listitem><para><emphasis><ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis> + <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis> The company where the Yocto Project build system Poky was first developed. OpenedHand has since been acquired by Intel Corporation.</para></listitem> <listitem><para><emphasis><ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis> The company who acquired OpenedHand in 2008 and continues development on the Yocto Project.</para></listitem> - <listitem><para><emphasis><ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis> + <listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis> The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives from and to which it contributes.</para></listitem> <listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'> - Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem> + BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem> <listitem><para><emphasis><ulink url='http://bitbake.berlios.de/manual/'> BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool. </para></listitem> @@ -96,11 +95,9 @@ The Yocto Project gladly accepts contributions. 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'> - How to Submit a Change</ulink> in - <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'> - The Yocto Project Development Manual</ulink>. + For information on how to do both, see the + "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>" + section in the Yocto Project Development Manual. </para> </section> diff --git a/documentation/poky-ref-manual/style.css b/documentation/poky-ref-manual/style.css index 087e45c1fb..914eb23e26 100644 --- a/documentation/poky-ref-manual/style.css +++ b/documentation/poky-ref-manual/style.css @@ -654,7 +654,7 @@ hr { .tip, .warning, .caution, .note { - border-color: #aaa; + border-color: #fff; } @@ -662,24 +662,24 @@ hr { .warning table th, .caution table th, .note table th { - border-bottom-color: #aaa; + border-bottom-color: #fff; } .warning { - background-color: #fea; + background-color: #f0f0f2; } .caution { - background-color: #fea; + background-color: #f0f0f2; } .tip { - background-color: #eff; + background-color: #f0f0f2; } .note { - background-color: #dfc; + background-color: #f0f0f2; } .glossary dl dt, @@ -946,8 +946,8 @@ table { .tip, .note { - background: #666666; - color: #fff; + background: #f0f0f2; + color: #333; padding: 20px; margin: 20px; } @@ -958,11 +958,26 @@ table { margin: 0em; font-size: 2em; font-weight: bold; - color: #fff; + color: #333; } .tip a, .note a { - color: #fff; + color: #333; text-decoration: underline; } + +.footnote { + font-size: small; + color: #333; +} + +/* Changes the announcement text */ +.tip h3, +.warning h3, +.caution h3, +.note h3 { + font-size:large; + color: #00557D; +} + diff --git a/documentation/poky-ref-manual/technical-details.xml b/documentation/poky-ref-manual/technical-details.xml new file mode 100644 index 0000000000..17840c58f1 --- /dev/null +++ b/documentation/poky-ref-manual/technical-details.xml @@ -0,0 +1,569 @@ +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > + +<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='&YOCTO_DOCS_DEV_URL;#yocto-project-terms'>Yocto Project Terms</ulink>" + section in the Yocto Project Development Manual. + </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 <packagename></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 referring 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 + rebuilding 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 working 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> + At the code level, there are a variety of ways both the basehash and the + dependent task hashes can be influenced. + Within the BitBake configuration file, we can give BitBake some extra information + to help it construct the basehash. + 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" + </literallayout> + The previous example actually excludes + <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link> + since it is actually constructed as a path within + <filename>TMPDIR</filename>, which is on + the whitelist. + </para> + + <para> + The rules for deciding which hashes of dependent tasks to include through + dependency chains are more complex and are generally accomplished with a + python function. + The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples + of this and also illustrates how you can insert your own policy into the system + if so desired. + This file defines the two basic signature generators <filename>OE-Core</filename> + uses: "OEBasic" and "OEBasicHash". + By default, there is a dummy "noop" signature handler enabled in BitBake. + This means that behavior is unchanged from previous versions. + <filename>OE-Core</filename> uses the "OEBasic" signature handler by default + through this setting in the <filename>bitbake.conf</filename> file: + <literallayout class='monospaced'> + BB_SIGNATURE_HANDLER ?= "OEBasic" + </literallayout> + The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the + "OEBasic" 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 <link linkend='var-PR'><filename>PR</filename></link> + values and changes to metadata automatically ripple across the build. + Currently, this behavior is not the default behavior for <filename>OE-Core</filename> + but is the default in <filename>poky</filename>. + </para> + + <para> + It is also worth noting that the end result of these signature generators is to + make some dependency and hash information available to the build. + This information includes: + <literallayout class='monospaced'> + BB_BASEHASH_task-<taskname> - the base hashes for each task in the recipe + BB_BASEHASH_<filename:taskname> - the base hashes for each dependent task + BBHASHDEPS_<filename:taskname> - The task dependencies for each task + BB_TASKHASH - the hash of the currently running task + </literallayout> + </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 multiple 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 statements + 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='&YOCTO_GIT_URL;/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>. + </note> + </section> + </section> +</section> + +</chapter> +<!-- +vim: expandtab tw=80 ts=4 +--> diff --git a/documentation/poky-ref-manual/usingpoky.xml b/documentation/poky-ref-manual/usingpoky.xml index 7b24841ac0..914a0f5771 100644 --- a/documentation/poky-ref-manual/usingpoky.xml +++ b/documentation/poky-ref-manual/usingpoky.xml @@ -1,218 +1,89 @@ <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > + <chapter id='usingpoky'> <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. - </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>. + 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> - <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> +<section id='usingpoky-build'> + <title>Running a Build</title> <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. + You can find general information on how to build an image using the + Yocto Project in the + "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" + section of The Yocto Project Quick Start. + This section provides a summary of the build process and provides information + for less obvious aspects of the build process. </para> - <section id='usingpoky-components-bitbake'> - <title>BitBake</title> + <section id='build-overview'> + <title>Build Overview</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: + 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'> - $ bitbake --help + $ source oe-init-build-env [build_dir] </literallayout> </para> <para> - The most common usage for BitBake is <filename>bitbake <packagename></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. + 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> - 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. + Once the Yocto Project build environment is set up, you can build a target using: + <literallayout class='monospaced'> + $ bitbake <target> + </literallayout> </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. + 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 the Yocto Project supports, see the + "<link linkend="ref-images">Reference: Images</link>" appendix. </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> + <note> + Building an image without GNU Public License Version 3 (GPLv3) components is + only supported for minimal and base images. + See the "<link linkend='ref-images'>Reference: Images</link>" appendix for more information. + </note> </section> - <section id='usingpoky-components-configuration'> - <title>Configuration</title> + <section id='building-an-image-using-gpl-components'> + <title>Building an Image Using GPL Components</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). + 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-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'> - Building an Image</ulink> section of the - <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'> - Yocto Project Quick Start</ulink>. - This section provides a quick overview. - </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> - 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> - Once the Yocto Project build environment is set up, you can build a target using: - <literallayout class='monospaced'> - $ bitbake <target> - </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> - - <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> - 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> - <section id='usingpoky-install'> <title>Installing and Using the Result</title> @@ -222,10 +93,8 @@ <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'> - 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'> - Yocto Project Quick Start</ulink>. + "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>" + section in the Yocto Project Quick Start. For information about how to install these images, see the documentation for your particular board/machine. </para> @@ -310,7 +179,7 @@ You can view a list of tasks in a given package by running the <filename>listtasks</filename> task as follows: <literallayout class='monospaced'> - $ bitbake matchbox-desktop -c + $ bitbake matchbox-desktop -c listtasks </literallayout> The results are in the file <filename>${WORKDIR}/temp/log.do_listtasks</filename>. </para> @@ -426,7 +295,7 @@ if fatal_error: bb.fatal("fatal_error detected, unable to print the task list") bb.plain("The tasks present are abc") - bb.debug(2, "Finished figureing out the tasklist") + bb.debug(2, "Finished figuring out the tasklist") } </literallayout> </para> diff --git a/documentation/poky.ent b/documentation/poky.ent new file mode 100644 index 0000000000..bb9a6e2564 --- /dev/null +++ b/documentation/poky.ent @@ -0,0 +1,48 @@ +<!ENTITY DISTRO "1.1.2"> +<!ENTITY DISTRO_NAME "edison"> +<!ENTITY YOCTO_DOC_VERSION "1.1.2"> +<!ENTITY POKYVERSION "6.0.2"> +<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;"> +<!ENTITY COPYRIGHT_YEAR "2010-2012"> +<!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org"> +<!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org"> +<!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org"> +<!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org"> +<!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org"> +<!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org"> +<!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org"> +<!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org"> +<!ENTITY OE_HOME_URL "http://www.openembedded.org"> +<!ENTITY OE_DOCS_URL "http://docs.openembedded.org"> +<!ENTITY OH_HOME_URL "http://o-hand.com"> +<!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/"> +<!ENTITY BITBAKE_DOCS_URL "http://bitbake.berlios.de/manual/"> +<!ENTITY ECLIPSE_MAIN_URL "http://www.eclipse.org/downloads"> +<!ENTITY ECLIPSE_DL_URL "http://download.eclipse.org"> +<!ENTITY ECLIPSE_DL_PLUGIN_URL "&YOCTO_DL_URL;/releases/eclipse-plugin/&DISTRO;"> +<!ENTITY ECLIPSE_UPDATES_URL "&ECLIPSE_DL_URL;/tm/updates/3.3"> +<!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo"> +<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;tools/cdt/releases/indigo"> +<!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs"> +<!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/"> +<!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010"> +<!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/"> +<!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/"> +<!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;"> +<!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/"> +<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/indigo;"> +<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer"> +<!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2"> +<!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines"> +<!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu"> +<!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2"> +<!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2"> +<!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html"> +<!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html"> +<!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/poky-ref-manual/poky-ref-manual.html"> +<!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html"> +<!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html"> +<!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html"> +<!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;"> +<!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2"> +<!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env"> diff --git a/documentation/yocto-project-qs/style.css b/documentation/yocto-project-qs/style.css index 21caf85da4..b8fdc3c265 100644 --- a/documentation/yocto-project-qs/style.css +++ b/documentation/yocto-project-qs/style.css @@ -654,7 +654,7 @@ hr { .tip, .warning, .caution, .note { - border-color: #aaa; + border-color: #fff; } @@ -662,24 +662,24 @@ hr { .warning table th, .caution table th, .note table th { - border-bottom-color: #aaa; + border-bottom-color: #fff; } .warning { - background-color: #fea; + background-color: #f0f0f2; } .caution { - background-color: #fea; + background-color: #f0f0f2; } .tip { - background-color: #eff; + background-color: #f0f0f2; } .note { - background-color: #dfc; + background-color: #f0f0f2; } .glossary dl dt, @@ -946,8 +946,8 @@ table { .tip, .note { - background: #666666; - color: #fff; + background: #f0f0f2; + color: #333; padding: 20px; margin: 20px; } @@ -958,11 +958,26 @@ table { margin: 0em; font-size: 2em; font-weight: bold; - color: #fff; + color: #333; } .tip a, .note a { - color: #fff; + color: #333; text-decoration: underline; } + +.footnote { + font-size: small; + color: #333; +} + +/* Changes the announcement text */ +.tip h3, +.warning h3, +.caution h3, +.note h3 { + font-size:large; + color: #00557D; +} + diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 3003f06cd0..ccc5cd6057 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -1,12 +1,13 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <article id='intro'> <imagedata fileref="figures/yocto-project-transp.png" width="6in" depth="1in" align="right" scale="25" /> <section id='fake-title'> - <title>Yocto Project Quick Start</title> - <para>Copyright © 2010-2011 Linux Foundation</para> + <title>The Yocto Project Quick Start</title> + <para>Copyright © ©RIGHT_YEAR; Linux Foundation</para> </section> <section id='welcome'> @@ -18,6 +19,7 @@ Amongst other things, the Yocto Project uses the Poky build system to construct complete Linux images. </para> + <para> This short document will give you some basic information about the environment as well as let you experience it in its simplest form. @@ -26,26 +28,28 @@ This document steps you through a simple example showing you how to build a small image and run it using the QEMU emulator. </para> + <para> - For complete information on the Yocto Project, you should check out the - <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>. - Through the website, you can find the latest builds, breaking news, full development - documentation, and a - rich Yocto Project Development Community into which you can tap. - </para> - <para> - 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'> - The Yocto Project Reference Manual</ulink> helpful. + For more detailed information on the Yocto Project, you should check out these resources: + <itemizedlist> + <listitem><para><emphasis>Website:</emphasis> The <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> + provides the latest builds, breaking news, full development documentation, and a rich Yocto + Project Development Community into which you can tap. + </para></listitem> + <listitem><para><emphasis>FAQs:</emphasis> Lists commonly asked Yocto Project questions and answers. + You can find two FAQs: <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>Yocto Project FAQ</ulink> on + a wiki, and the + <ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink> appendix in the + The Yocto Project Reference Manual. + </para></listitem> + </itemizedlist> </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='&YOCTO_DOCS_QS_URL;'> Yocto Project Quick Start</ulink> on - the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website. + the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. For the latest version of this manual, see the manual on the website. </note> </section> @@ -156,11 +160,11 @@ <listitem><para>openSUSE</para></listitem> </itemizedlist> For a list of the distributions under validation and their status, see the - <ulink url='https://wiki.yoctoproject.org/wiki/Distribution_Support'>Distribution + <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink> wiki page. <note> For notes about using the Yocto Project on a RHEL 4-based host, see the - <ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink> + <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink> wiki page. </note> </para> @@ -174,12 +178,12 @@ If you attempt to use a distribution not in the above list, you may or may not have success - you are venturing into untested territory. Refer to - <ulink url='http://openembedded.net/index.php?title=OEandYourDistro&action=historysubmit&diff=4309&okdid=4225'>OE and Your Distro</ulink> and - <ulink url='http://openembedded.net/index.php?title=Required_software&action=historysubmit&diff=4311&oldid=4251'>Required Software</ulink> + <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro&action=historysubmit&diff=4309&okdid=4225'>OE and Your Distro</ulink> and + <ulink url='&OE_HOME_URL;/index.php?title=Required_software&action=historysubmit&diff=4311&oldid=4251'>Required Software</ulink> for information for other distributions used with the OpenEmbedded project, which might be a starting point for exploration. If you go down this path, you should expect problems. - When you do, please go to <ulink url='http://bugzilla.yoctoproject.org'>Yocto Project Bugzilla</ulink> + When you do, please go to <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink> and submit a bug. We are interested in hearing about your experience. </para></note> @@ -191,50 +195,78 @@ <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 \ + unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk fop \ + python-pysqlite2 diffstat help2man make gcc build-essential xsltproc \ 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 \ - docbook-style-dsssl sed docbook-style-xsl docbook-dtds \ + docbook-style-dsssl sed docbook-style-xsl docbook-dtds fop xsltproc \ docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \ groff linuxdoc-tools patch linuxdoc-tools cmake help2man \ 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'> - $ sudo zypper install python gcc gcc-c++ libtool \ - subversion git chrpath automake \ - help2man diffstat texinfo mercurial wget - </literallayout> - + <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 fop \ + subversion git chrpath automake make wget help2man xsltproc \ + diffstat texinfo mercurial freeglut-devel libSDL-devel + </literallayout> + </section> </section> <section id='releases'> @@ -242,13 +274,13 @@ <para> You can download the latest Yocto Project release by going to the - <ulink url="http://yoctoproject.org/download">Yocto Project Download page</ulink>. + <ulink url="&YOCTO_HOME_URL;/download">Yocto Project Download page</ulink>. Just go to the page and click the "Yocto Downloads" link found in the "Download" navigation pane to the right to view all available Yocto Project releases. Then, click the "Yocto Release" link for the release you want from the list to begin the download. Nightly and developmental builds are also maintained at - <ulink url="http://autobuilder.yoctoproject.org/nightly/"></ulink>. + <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>. However, for this document a released version of Yocto Project is used. </para> @@ -257,10 +289,8 @@ 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 - Project Release</ulink>" item in - <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto Project - Development Manual</ulink>. + "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto + Project Release</ulink>" item in The Yocto Project Development Manual. </para> </section> </section> @@ -269,7 +299,7 @@ <title>A Quick Test Run</title> <para> - Now that you have your system requirements in order, you can give Yocto Project a try. + Now that you have your system requirements in order, you can give the Yocto Project a try. This section presents some steps that let you do the following: </para> @@ -315,28 +345,28 @@ By default, the Yocto Project searches for source code using a pre-determined order through a set of locations. 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 + the FAQ entry "How does the Yocto Project build system 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='&YOCTO_DOCS_REF_URL;#faq'> The Yocto Project Reference Manual</ulink>. </para></note> <para> <literallayout class='monospaced'> - $ wget http://www.downloads.yoctoproject.org/releases/yocto/yocto-1.1/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 &YOCTO_POKY_DL_URL; + $ tar xjf &YOCTO_POKY;.tar.bz2 + $ source &OE_INIT_PATH; &YOCTO_POKY;-build </literallayout> </para> <tip><para> To help conserve disk space during builds, you can add the following statement to your project's configuration file, which for this example - is <filename>edison-6.0-build/conf/local.conf</filename>. + is <filename>&YOCTO_POKY;-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'> - INHERIT += rm_work + INHERIT += "rm_work" </literallayout> </para></tip> @@ -345,16 +375,16 @@ release tarball from the source repositories using the <filename>wget</filename> command. Alternatively, you can go to the - <ulink url='http://www.yoctoproject.org/download'>Yocto Project website</ulink> - Downloads page to retrieve the tarball.</para></listitem> + <ulink url='&YOCTO_HOME_URL;/download'>Yocto Project website's Downloads page</ulink> + 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 + them into a directory named <filename>&YOCTO_POKY;</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>&YOCTO_POKY;-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 @@ -378,15 +408,12 @@ <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='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the + <ulink url='&YOCTO_DOCS_REF_URL;#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 uncomment - the lines and set the variable - <filename>BB_NUMBER_THREADS</filename> equal to twice the number of your + the lines and set both variables equal to twice the number of your host's 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> @@ -395,11 +422,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='&YOCTO_DOCS_REF_URL;#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'> - The Yocto Project Reference Manual</ulink>. + "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" + in The Yocto Project Reference Manual. </para> <para> @@ -407,16 +433,16 @@ <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='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>" section in + The Yocto Project Reference Manual. <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'> - The Yocto Project Reference Manual</ulink>. + see the + <ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink> in The Yocto Project Reference + Manual. </para></note> The final command runs the image: <literallayout class='monospaced'> @@ -454,7 +480,7 @@ </para> <itemizedlist> - <listitem><para>Install the stand-alone Yocto toolchain tarball.</para></listitem> + <listitem><para>Install the appropriate stand-alone Yocto toolchain tarball.</para></listitem> <listitem><para>Download the pre-built image that will boot with QEMU. You need to be sure to get the QEMU image that matches your target machine’s architecture (e.g. x86, ARM, etc.).</para></listitem> @@ -469,9 +495,9 @@ <para> You can download the pre-built toolchain, which includes the <filename>runqemu</filename> script and support files, from the appropriate directory under - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/toolchain/'></ulink>. + <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>. Toolchains are available for 32-bit and 64-bit development systems from the - <filename>i686</filename> and <filename>x86_64</filename> directories, 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 @@ -479,7 +505,7 @@ </para> <literallayout class='monospaced'> - poky-eglibc<<emphasis>host_system</emphasis>>-<<emphasis>arch</emphasis>>-toolchain-gmae-<<emphasis>release</emphasis>>.tar.bz2 + poky-eglibc-<<emphasis>host_system</emphasis>>-<<emphasis>arch</emphasis>>-toolchain-gmae-<<emphasis>release</emphasis>>.tar.bz2 Where: <<emphasis>host_system</emphasis>> is a string representing your development system: @@ -497,7 +523,7 @@ </para> <literallayout class='monospaced'> - poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2 + poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2 </literallayout> <para> @@ -510,16 +536,15 @@ <para> <literallayout class='monospaced'> $ cd / - $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2 + $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.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) User's Guide</ulink>. + "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and + "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in The Yocto Project Application Development Toolkit (ADT) + User's Guide. </para> </section> @@ -528,11 +553,11 @@ <para> You can download the pre-built Linux kernel suitable for running in the QEMU emulator from - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu'></ulink>. + <ulink url='&YOCTO_QEMU_DL_URL;'></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>, - <filename>qemux86</filename>, and <filename>qemux86_64</filename>. + <filename>qemux86</filename>, and <filename>qemux86-64</filename>. </para> <para> @@ -549,9 +574,8 @@ <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 - Yocto Project Development Manual</ulink>. + "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" section of + The Yocto Project Development Manual. </para> </section> @@ -560,7 +584,7 @@ <para> You can also download the filesystem image suitable for your target architecture from - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu'></ulink>. + <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>. Again, be sure to use the filesystem that matches the architecture you want to simulate. </para> @@ -571,7 +595,7 @@ You must use the <filename>ext3</filename> form when booting an image using the QEMU emulator. The <filename>tar</filename> form can be flattened out in your host development system - and used for Yocto Project build purposes. + and used for build purposes with the Yocto Project. <literallayout class='monospaced'> core-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.ext3 core-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.tar.bz2 @@ -580,7 +604,7 @@ <<emphasis>profile</emphasis>> is the filesystem image's profile: 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='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual. <<emphasis>arch</emphasis>> is a string representing the target architecture: x86, x86-64, ppc, mips, or arm. @@ -595,7 +619,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-<<emphasis>arch</emphasis>>-poky-linux-<<emphasis>if</emphasis>> + $ source &YOCTO_ADTPATH_DIR;/environment-setup-<<emphasis>arch</emphasis>>-poky-linux-<<emphasis>if</emphasis>> Where: <<emphasis>arch</emphasis>> is a string representing the target architecture: @@ -625,11 +649,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 - that the kernel and filesystem are for a 32-bit target architecture. + This example assumes the root filesystem (<filename>.ext3</filename> file) and + the pre-built kernel image file both reside in your home directory. + 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 \ + $ cd $HOME + $ source &YOCTO_ADTPATH_DIR;/environment-setup-i586-poky-linux + $ runqemu qemux86 bzImage-qemux86.bin \ core-image-sato-qemux86.ext3 </literallayout> </para> diff --git a/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb b/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb index 02d56f6abc..b10c1d0c37 100644 --- a/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb +++ b/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 diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf index c88f97dcae..734e92e036 100644 --- a/meta-yocto/conf/distro/poky.conf +++ b/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.2)" +DISTRO_VERSION = "1.1.2" 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}" diff --git a/meta-yocto/conf/local.conf.sample.extended b/meta-yocto/conf/local.conf.sample.extended index a42774cfac..e8c0c16bbf 100644 --- a/meta-yocto/conf/local.conf.sample.extended +++ b/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 diff --git a/meta-yocto/conf/machine/atom-pc.conf b/meta-yocto/conf/machine/atom-pc.conf index da795cd430..bc24e481c2 100644 --- a/meta-yocto/conf/machine/atom-pc.conf +++ b/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" diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass index da32f1ded8..5b5b8b65de 100644 --- a/meta/classes/autotools.bbclass +++ b/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 diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass index 918d859c93..d020964a01 100644 --- a/meta/classes/base.bbclass +++ b/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) diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass index 49ee85ea72..09f5b67c94 100644 --- a/meta/classes/bootimg.bbclass +++ b/meta/classes/bootimg.bbclass @@ -62,13 +62,52 @@ build_boot_bin() { install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys ${HDDDIR}/ldlinux.sys - # Do a little math, bash style - #BLOCKS=`du -s ${HDDDIR} | cut -f 1` - BLOCKS=`du -bks ${HDDDIR} | cut -f 1` - SIZE=`expr $BLOCKS + ${BOOTIMG_EXTRA_SPACE}` - - mkdosfs -n ${BOOTIMG_VOLUME_ID} -d ${HDDDIR} \ - -C ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg $SIZE + # Calculate the size required for the final image including the + # data and filesystem overhead. + # Sectors: 512 bytes + # Blocks: 1024 bytes + + # Determine the sector count just for the data + SECTORS=$(expr $(du --apparent-size -ks ${HDDDIR} | cut -f 1) \* 2) + + # Account for the filesystem overhead. This includes directory + # entries in the clusters as well as the FAT itself. + # Assumptions: + # FAT32 (12 or 16 may be selected by mkdosfs, but the extra + # padding will be minimal on those smaller images and not + # worth the logic here to caclulate the smaller FAT sizes) + # < 16 entries per directory + # 8.3 filenames only + + # 32 bytes per dir entry + DIR_BYTES=$(expr $(find ${HDDDIR} | tail -n +2 | wc -l) \* 32) + # 32 bytes for every end-of-directory dir entry + DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${HDDDIR} -type d | tail -n +2 | wc -l) \* 32)) + # 4 bytes per FAT entry per sector of data + FAT_BYTES=$(expr $SECTORS \* 4) + # 4 bytes per FAT entry per end-of-cluster list + FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${HDDDIR} -type d | tail -n +2 | wc -l) \* 4)) + + # Use a ceiling function to determine FS overhead in sectors + DIR_SECTORS=$(expr $(expr $DIR_BYTES + 511) / 512) + # There are two FATs on the image + FAT_SECTORS=$(expr $(expr $(expr $FAT_BYTES + 511) / 512) \* 2) + SECTORS=$(expr $SECTORS + $(expr $DIR_SECTORS + $FAT_SECTORS)) + + # Determine the final size in blocks accounting for some padding + BLOCKS=$(expr $(expr $SECTORS / 2) + ${BOOTIMG_EXTRA_SPACE}) + + + # Ensure total sectors is an integral number of sectors per + # track or mcopy will complain. Sectors are 512 bytes, and we + # generate images with 32 sectors per track. This calculation is + # done in blocks, thus the mod by 16 instead of 32. + BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16))) + + IMG=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg + mkdosfs -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS} + # Copy HDDDIR recursively into the image file directly + mcopy -i ${IMG} -s ${HDDDIR}/* ::/ syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg chmod 644 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg diff --git a/meta/classes/buildstats.bbclass b/meta/classes/buildstats.bbclass index 55cbb3cee3..f174964cc0 100644 --- a/meta/classes/buildstats.bbclass +++ b/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) diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass index 79b962a360..18ae805f7b 100644 --- a/meta/classes/distutils.bbclass +++ b/meta/classes/distutils.bbclass @@ -72,3 +72,5 @@ distutils_do_install() { } EXPORT_FUNCTIONS do_compile do_install + +export LDSHARED="${CCLD} -shared" diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index f17e989289..e9a3aa6156 100644 --- a/meta/classes/image.bbclass +++ b/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. @@ -78,6 +76,8 @@ inherit image-${IMAGE_TYPE} python () { deps = bb.data.getVarFlag('do_rootfs', 'depends', d) or "" for type in (bb.data.getVar('IMAGE_FSTYPES', d, True) or "").split(): + if type == "live": + type = "ext3" for dep in ((bb.data.getVar('IMAGE_DEPENDS_%s' % type, d) or "").split() or []): deps += " %s:do_populate_sysroot" % dep for dep in (bb.data.getVar('EXTRA_IMAGEDEPENDS', d, True) or "").split(): diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass index c24b326451..1f55b2cb86 100644 --- a/meta/classes/image_types.bbclass +++ b/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" diff --git a/meta/classes/imagetest-qemu.bbclass b/meta/classes/imagetest-qemu.bbclass index 18798e025c..e3a65f0419 100644 --- a/meta/classes/imagetest-qemu.bbclass +++ b/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(): diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass index 3f93bf5df2..baf35f00cc 100644 --- a/meta/classes/license.bbclass +++ b/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" diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass index 572df0d295..53c16b7389 100644 --- a/meta/classes/module.bbclass +++ b/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} \ diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass index 1aed2a9f97..6eb3bc3756 100644 --- a/meta/classes/multilib.bbclass +++ b/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", "") diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass index 9a41f19dc6..ba8b0bf25e 100644 --- a/meta/classes/native.bbclass +++ b/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}" diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass index a9c510d27c..deaa87b922 100644 --- a/meta/classes/package.bbclass +++ b/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: diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass index c0893a6cda..9a1e5852c4 100644 --- a/meta/classes/package_ipk.bbclass +++ b/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 diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass index 7f425837be..b511afd374 100644 --- a/meta/classes/package_rpm.bbclass +++ b/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 @@ -398,16 +379,49 @@ package_install_internal_rpm () { fi - cat ${target_rootfs}/install/install_solution.manifest > ${target_rootfs}/install/total_solution.manifest + # If base-passwd or shadow are in the list of packages to install, + # ensure they are installed first to support later packages that + # may create custom users/groups (fixes Yocto bug #2127) + infile=${target_rootfs}/install/install_solution.manifest + outfile=${target_rootfs}/install/total_solution.manifest + cat $infile | grep /base-passwd-[0-9] > $outfile || true + cat $infile | grep /shadow-[0-9] >> $outfile || true + cat $infile | grep -v /shadow-[0-9] | grep -v /base-passwd-[0-9] >> $outfile 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 +504,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 +714,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 +796,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 +962,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! diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass index 762216345a..5f9765ce98 100644 --- a/meta/classes/patch.bbclass +++ b/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}" diff --git a/meta/classes/populate_sdk.bbclass b/meta/classes/populate_sdk.bbclass index 1ef72cfeb2..5aa8e92b87 100644 --- a/meta/classes/populate_sdk.bbclass +++ b/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} diff --git a/meta/classes/populate_sdk_deb.bbclass b/meta/classes/populate_sdk_deb.bbclass index be7b5520c4..98c2425ebf 100644 --- a/meta/classes/populate_sdk_deb.bbclass +++ b/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" diff --git a/meta/classes/populate_sdk_ipk.bbclass b/meta/classes/populate_sdk_ipk.bbclass index 79259f80d6..c256c69d48 100644 --- a/meta/classes/populate_sdk_ipk.bbclass +++ b/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,19 @@ 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}" + + export D=${INSTALL_ROOTFS_IPK} + export OFFLINE_ROOT=${INSTALL_ROOTFS_IPK} + export IPKG_OFFLINE_ROOT=${INSTALL_ROOTFS_IPK} + export OPKG_OFFLINE_ROOT=${IPKG_OFFLINE_ROOT} 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 diff --git a/meta/classes/populate_sdk_rpm.bbclass b/meta/classes/populate_sdk_rpm.bbclass index 9989d0abfd..5362793232 100644 --- a/meta/classes/populate_sdk_rpm.bbclass +++ b/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" diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass index e02b8165b7..37241274d2 100644 --- a/meta/classes/rootfs_ipk.bbclass +++ b/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 diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass index dd370b263a..53c5b75437 100644 --- a/meta/classes/rootfs_rpm.bbclass +++ b/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 diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass index 91f209a9cf..d2a45c3b8f 100644 --- a/meta/classes/sstate.bbclass +++ b/meta/classes/sstate.bbclass @@ -10,12 +10,14 @@ SSTATE_PKGSPEC = "sstate-${PN}-${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}-$ SSTATE_PKGNAME = "${SSTATE_PKGSPEC}${BB_TASKHASH}" SSTATE_PKG = "${SSTATE_DIR}/${SSTATE_PKGNAME}" -SSTATE_SCAN_CMD ?= "find ${SSTATE_BUILDDIR} \( -name "*.la" -o -name "*-config" \) -type f" +SSTATE_SCAN_FILES ?= "*.la *-config" +SSTATE_SCAN_CMD ?= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name \"".join(d.getVar("SSTATE_SCAN_FILES", True).split())}" \) -type f' BB_HASHFILENAME = "${SSTATE_PKGNAME}" SSTATE_MANMACH ?= "${SSTATE_PKGARCH}" +SSTATEPREINSTFUNCS ?= "" SSTATEPOSTINSTFUNCS ?= "" python () { @@ -114,15 +116,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) @@ -168,6 +171,10 @@ def sstate_installpkg(ss, d): bb.data.setVar('SSTATE_INSTDIR', sstateinst, d) bb.data.setVar('SSTATE_PKG', sstatepkg, d) + + for preinst in (d.getVar('SSTATEPREINSTFUNCS', True) or '').split(): + bb.build.exec_func(preinst, d) + bb.build.exec_func('sstate_unpack_package', d) # Fixup hardcoded paths @@ -258,10 +265,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 +367,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) @@ -441,12 +453,14 @@ python sstate_task_postfunc () { # sstate_create_package () { cd ${SSTATE_BUILDDIR} + TFILE=`mktemp ${SSTATE_PKG}.XXXXXXXX` # Need to handle empty directories if [ "$(ls -A)" ]; then - tar -czf ${SSTATE_PKG} * + tar -czf $TFILE * else - tar -cz --file=${SSTATE_PKG} --files-from=/dev/null + tar -cz --file=$TFILE --files-from=/dev/null fi + mv $TFILE ${SSTATE_PKG} cd ${WORKDIR} rm -rf ${SSTATE_BUILDDIR} diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass index 1e03a04a8c..6ecfa16a5f 100644 --- a/meta/classes/useradd.bbclass +++ b/meta/classes/useradd.bbclass @@ -1,14 +1,19 @@ -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" - -# This preinstall function will be run in two contexts: once for the -# native sysroot (as invoked by the useradd_sysroot() wrapper), and -# also as the preinst script in the target package. +DEPENDS_append = "${USERADDDEPENDS}" +USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow" +USERADDDEPENDS_virtclass-cross = "" +USERADDDEPENDS_virtclass-native = "" +USERADDDEPENDS_virtclass-nativesdk = "" + +# This preinstall function can be run in four different contexts: +# +# a) Before do_install +# b) At do_populate_sysroot_setscene when installing from sstate packages +# c) As the preinst script in the target package at do_rootfs time +# d) As the preinst script in the target package on device as a package upgrade +# useradd_preinst () { OPT="" SYSROOT="" @@ -37,7 +42,29 @@ 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 + count=1 + while true; do + eval $PSEUDO groupadd $OPT $opts || true + group_exists=`grep "^$groupname:" $SYSROOT/etc/group || true` + if test "x$group_exists" = "x"; then + # File locking issues can require us to retry the command + echo "WARNING: groupadd command did not succeed. Retrying..." + sleep 1 + else + break + fi + count=`expr $count + 1` + if test $count = 11; then + echo "ERROR: tried running groupadd command 10 times without success, giving up" + exit 1 + fi + done + else + echo "Note: group $groupname already exists, not re-creating it" + fi if test "x$opts" = "x$remaining"; then break @@ -59,7 +86,23 @@ if test "x$USERADD_PARAM" != "x"; then username=`echo "$opts" | awk '{ print $NF }'` user_exists=`grep "^$username:" $SYSROOT/etc/passwd || true` if test "x$user_exists" = "x"; then - eval $PSEUDO useradd $OPT $opts + count=1 + while true; do + eval $PSEUDO useradd $OPT $opts || true + user_exists=`grep "^$username:" $SYSROOT/etc/passwd || true` + if test "x$user_exists" = "x"; then + # File locking issues can require us to retry the command + echo "WARNING: useradd command did not succeed. Retrying..." + sleep 1 + else + break + fi + count=`expr $count + 1` + if test $count = 11; then + echo "ERROR: tried running useradd command 10 times without success, giving up" + exit 1 + fi + done else echo "Note: username $username already exists, not re-creating it" fi @@ -74,8 +117,10 @@ fi } useradd_sysroot () { - export PSEUDO="${STAGING_DIR_NATIVE}${bindir}/pseudo" - export PSEUDO_LOCALSTATEDIR="${STAGING_DIR_TARGET}${localstatedir}/pseudo" + # Pseudo may (do_install) or may not (do_populate_sysroot_setscene) be running + # at this point so we're explicit about the environment so pseudo can load if + # not already present. + export PSEUDO="${FAKEROOTENV} PSEUDO_LOCALSTATEDIR=${STAGING_DIR_TARGET}${localstatedir}/pseudo ${STAGING_DIR_NATIVE}${bindir}/pseudo" # Explicitly set $D since it isn't set to anything # before do_install @@ -84,41 +129,54 @@ useradd_sysroot () { } useradd_sysroot_sstate () { - if [ "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] + if [ "${BB_CURRENTTASK}" = "package_setscene" ] then useradd_sysroot fi } -do_install[prefuncs] += "useradd_sysroot" -SSTATEPOSTINSTFUNCS += "useradd_sysroot_sstate" +do_install[prefuncs] += "${SYSROOTFUNC}" +SYSROOTFUNC = "useradd_sysroot" +SYSROOTFUNC_virtclass-cross = "" +SYSROOTFUNC_virtclass-native = "" +SYSROOTFUNC_virtclass-nativesdk = "" +SSTATEPREINSTFUNCS += "${SYSROOTPOSTFUNC}" +SYSROOTPOSTFUNC = "useradd_sysroot_sstate" +SYSROOTPOSTFUNC_virtclass-cross = "" +SYSROOTPOSTFUNC_virtclass-native = "" +SYSROOTPOSTFUNC_virtclass-nativesdk = "" + +USERADDSETSCENEDEPS = "base-passwd:do_populate_sysroot_setscene shadow-native:do_populate_sysroot_setscene ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene" +USERADDSETSCENEDEPS_virtclass-cross = "" +USERADDSETSCENEDEPS_virtclass-native = "" +USERADDSETSCENEDEPS_virtclass-nativesdk = "" +do_package_setscene[depends] = "${USERADDSETSCENEDEPS}" # 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 +199,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) } diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index b7bcc23890..56bc362eb6 100644 --- a/meta/conf/bitbake.conf +++ b/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 ??= "" diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf index b9da33ae4a..5ac1f0b61f 100644 --- a/meta/conf/multilib.conf +++ b/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}" diff --git a/meta/files/common-licenses/Adobe b/meta/files/common-licenses/Adobe new file mode 100644 index 0000000000..64779da1df --- /dev/null +++ b/meta/files/common-licenses/Adobe @@ -0,0 +1,14 @@ +Copyright 1990-1998 Adobe Systems Incorporated. +All Rights Reserved. + +Patents Pending + +NOTICE: All information contained herein is the property of Adobe +Systems Incorporated. + +Permission is granted for redistribution of this file provided +this copyright notice is maintained intact and that the contents +of this file are not altered in any way from its original form. + +PostScript and Display PostScript are trademarks of Adobe Systems +Incorporated which may be registered in certain jurisdictions. diff --git a/meta/files/common-licenses/BitstreamVera b/meta/files/common-licenses/BitstreamVera new file mode 100644 index 0000000000..e6f03aa57a --- /dev/null +++ b/meta/files/common-licenses/BitstreamVera @@ -0,0 +1,160 @@ +Bitstream Vera Fonts Copyright + +The fonts have a generous copyright, allowing derivative works (as +long as "Bitstream" or "Vera" are not in the names), and full +redistribution (so long as they are not *sold* by themselves). They +can be be bundled, redistributed and sold with any software. + +The fonts are distributed under the following copyright: + +Copyright +========= + +Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream +Vera is a trademark of Bitstream, Inc. + +Permission is hereby granted, free of charge, to any person obtaining +a copy of the fonts accompanying this license ("Fonts") and associated +documentation files (the "Font Software"), to reproduce and distribute +the Font Software, including without limitation the rights to use, +copy, merge, publish, distribute, and/or sell copies of the Font +Software, and to permit persons to whom the Font Software is furnished +to do so, subject to the following conditions: + +The above copyright and trademark notices and this permission notice +shall be included in all copies of one or more of the Font Software +typefaces. + +The Font Software may be modified, altered, or added to, and in +particular the designs of glyphs or characters in the Fonts may be +modified and additional glyphs or characters may be added to the +Fonts, only if the fonts are renamed to names not containing either +the words "Bitstream" or the word "Vera". + +This License becomes null and void to the extent applicable to Fonts +or Font Software that has been modified and is distributed under the +"Bitstream Vera" names. + +The Font Software may be sold as part of a larger software package but +no copy of one or more of the Font Software typefaces may be sold by +itself. + +THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT +OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL +BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR +OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, +OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR +OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT +SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. + +Except as contained in this notice, the names of Gnome, the Gnome +Foundation, and Bitstream Inc., shall not be used in advertising or +otherwise to promote the sale, use or other dealings in this Font +Software without prior written authorization from the Gnome Foundation +or Bitstream Inc., respectively. For further information, contact: +fonts at gnome dot org. + +Copyright FAQ +============= + +1. I don't understand the resale restriction... What gives? + +Bitstream is giving away these fonts, but wishes to ensure its +competitors can't just drop the fonts as is into a font sale system +and sell them as is. It seems fair that if Bitstream can't make money +from the Bitstream Vera fonts, their competitors should not be able to +do so either. You can sell the fonts as part of any software package, +however. + +2. I want to package these fonts separately for distribution and +sale as part of a larger software package or system. Can I do so? + +Yes. A RPM or Debian package is a "larger software package" to begin +with, and you aren't selling them independently by themselves. +See 1. above. + +3. Are derivative works allowed? +Yes! + +4. Can I change or add to the font(s)? +Yes, but you must change the name(s) of the font(s). + +5. Under what terms are derivative works allowed? + +You must change the name(s) of the fonts. This is to ensure the +quality of the fonts, both to protect Bitstream and Gnome. We want to +ensure that if an application has opened a font specifically of these +names, it gets what it expects (though of course, using fontconfig, +substitutions could still could have occurred during font +opening). You must include the Bitstream copyright. Additional +copyrights can be added, as per copyright law. Happy Font Hacking! + +6. If I have improvements for Bitstream Vera, is it possible they might get +adopted in future versions? + +Yes. The contract between the Gnome Foundation and Bitstream has +provisions for working with Bitstream to ensure quality additions to +the Bitstream Vera font family. Please contact us if you have such +additions. Note, that in general, we will want such additions for the +entire family, not just a single font, and that you'll have to keep +both Gnome and Jim Lyles, Vera's designer, happy! To make sense to add +glyphs to the font, they must be stylistically in keeping with Vera's +design. Vera cannot become a "ransom note" font. Jim Lyles will be +providing a document describing the design elements used in Vera, as a +guide and aid for people interested in contributing to Vera. + +7. I want to sell a software package that uses these fonts: Can I do so? + +Sure. Bundle the fonts with your software and sell your software +with the fonts. That is the intent of the copyright. + +8. If applications have built the names "Bitstream Vera" into them, +can I override this somehow to use fonts of my choosing? + +This depends on exact details of the software. Most open source +systems and software (e.g., Gnome, KDE, etc.) are now converting to +use fontconfig (see www.fontconfig.org) to handle font configuration, +selection and substitution; it has provisions for overriding font +names and subsituting alternatives. An example is provided by the +supplied local.conf file, which chooses the family Bitstream Vera for +"sans", "serif" and "monospace". Other software (e.g., the XFree86 +core server) has other mechanisms for font substitution. + +Show details Hide details + +Change log +r2011 by mark.nickel on Mar 3, 2011 Diff + +Majority of Multi-Line text editing is in +the commit. Also added some specific free +fonts to replace the existing set as we +need some additional font metrics that we +use in the Text Editing rendering +pipeline. + +You can see the font licenses in the +editor/fonts folder under each font. + +Still have some cleanup to do to add the +text formatting (left,right,center) as +... + +Go to: +Hide comments +Show comments + +Older revisions +All revisions of this file + +File info +Size: 5953 bytes, 123 lines +View raw file + +File properties + +svn:executable + * + + diff --git a/meta/files/common-licenses/DSSSL b/meta/files/common-licenses/DSSSL new file mode 100644 index 0000000000..7159dfbd66 --- /dev/null +++ b/meta/files/common-licenses/DSSSL @@ -0,0 +1,49 @@ +Copyright +--------- + +Copyright (C) 1997-2001 Norman Walsh + +The original inspiration for these stylesheets came from the +work of Jon Bosak, Anders Berglund, Tony Graham, Terry Allen, +James Clark, and many others. I am indebted to them and to the +community of users on dssslist@mulberrytech.com for making +substantial contributions to this work and for answering my many +questions. + +This software may be distributed under the same terms as Jade: + +Permission is hereby granted, free of charge, to any person +obtaining a copy of this software and associated documentation +files (the ``Software''), to deal in the Software without +restriction, including without limitation the rights to use, +copy, modify, merge, publish, distribute, sublicense, and/or +sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following +conditions: + +The above copyright notice and this permission notice shall be +included in all copies or substantial portions of the Software. + +Except as contained in this notice, the names of individuals +credited with contribution to this software shall not be used in +advertising or otherwise to promote the sale, use or other +dealings in this Software without prior written authorization +from the individuals in question. + +Any stylesheet derived from this Software that is publically +distributed will be identified with a different name and the +version strings in any derived Software will be changed so that +no possibility of confusion between the derived package and this +Software will exist. + +Warranty +-------- + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES +OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND +NONINFRINGEMENT. IN NO EVENT SHALL NORMAN WALSH OR ANY OTHER +CONTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, +WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +OTHER DEALINGS IN THE SOFTWARE. diff --git a/meta/files/common-licenses/EDL-1.0 b/meta/files/common-licenses/EDL-1.0 new file mode 100644 index 0000000000..53b1eb045d --- /dev/null +++ b/meta/files/common-licenses/EDL-1.0 @@ -0,0 +1,13 @@ +Eclipse Distribution License - v 1.0 + +Copyright (c) 2007, Eclipse Foundation, Inc. and its licensors. + +All rights reserved. + +Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. + * Neither the name of the Eclipse Foundation, Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/meta/files/common-licenses/Elfutils-Exception b/meta/files/common-licenses/Elfutils-Exception new file mode 100644 index 0000000000..627d769126 --- /dev/null +++ b/meta/files/common-licenses/Elfutils-Exception @@ -0,0 +1,12 @@ + This file describes the limits of the Exception under which you are allowed + to distribute Non-GPL Code in linked combination with Red Hat elfutils. + For the full text of the license, please see one of the header files + included with the source distribution or the file COPYING found in the + top level directory of the source. + + The Approved Interfaces are the functions declared in the files: + + libelf.h + libdw.h + libdwfl.h + diff --git a/meta/files/common-licenses/FSF-Unlimited b/meta/files/common-licenses/FSF-Unlimited new file mode 100644 index 0000000000..010a981afc --- /dev/null +++ b/meta/files/common-licenses/FSF-Unlimited @@ -0,0 +1,4 @@ +Copyright (C) 1997-2010 Free Software Foundation, Inc. +This file is free software; the Free Software Foundation +gives unlimited permission to copy and/or distribute it, +with or without modifications, as long as this notice is preserved. diff --git a/meta/files/common-licenses/FreeType b/meta/files/common-licenses/FreeType new file mode 100644 index 0000000000..b7d4d11c0f --- /dev/null +++ b/meta/files/common-licenses/FreeType @@ -0,0 +1,170 @@ + The FreeType Project LICENSE + ---------------------------- + + 2006-Jan-27 + + Copyright 1996-2002, 2006 by + David Turner, Robert Wilhelm, and Werner Lemberg + + + +Introduction +============ + + The FreeType Project is distributed in several archive packages; + some of them may contain, in addition to the FreeType font engine, + various tools and contributions which rely on, or relate to, the + FreeType Project. + + This license applies to all files found in such packages, and + which do not fall under their own explicit license. The license + affects thus the FreeType font engine, the test programs, + documentation and makefiles, at the very least. + + This license was inspired by the BSD, Artistic, and IJG + (Independent JPEG Group) licenses, which all encourage inclusion + and use of free software in commercial and freeware products + alike. As a consequence, its main points are that: + + o We don't promise that this software works. However, we will be + interested in any kind of bug reports. (`as is' distribution) + + o You can use this software for whatever you want, in parts or + full form, without having to pay us. (`royalty-free' usage) + + o You may not pretend that you wrote this software. If you use + it, or only parts of it, in a program, you must acknowledge + somewhere in your documentation that you have used the + FreeType code. (`credits') + + We specifically permit and encourage the inclusion of this + software, with or without modifications, in commercial products. + We disclaim all warranties covering The FreeType Project and + assume no liability related to The FreeType Project. + + + Finally, many people asked us for a preferred form for a + credit/disclaimer to use in compliance with this license. We thus + encourage you to use the following text: + + """ + Portions of this software are copyright � <year> The FreeType + Project (www.freetype.org). All rights reserved. + """ + + Please replace <year> with the value from the FreeType version you + actually use. + + +Legal Terms +=========== + +0. Definitions +-------------- + + Throughout this license, the terms `package', `FreeType Project', + and `FreeType archive' refer to the set of files originally + distributed by the authors (David Turner, Robert Wilhelm, and + Werner Lemberg) as the `FreeType Project', be they named as alpha, + beta or final release. + + `You' refers to the licensee, or person using the project, where + `using' is a generic term including compiling the project's source + code as well as linking it to form a `program' or `executable'. + This program is referred to as `a program using the FreeType + engine'. + + This license applies to all files distributed in the original + FreeType Project, including all source code, binaries and + documentation, unless otherwise stated in the file in its + original, unmodified form as distributed in the original archive. + If you are unsure whether or not a particular file is covered by + this license, you must contact us to verify this. + + The FreeType Project is copyright (C) 1996-2000 by David Turner, + Robert Wilhelm, and Werner Lemberg. All rights reserved except as + specified below. + +1. No Warranty +-------------- + + THE FREETYPE PROJECT IS PROVIDED `AS IS' WITHOUT WARRANTY OF ANY + KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, + WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + PURPOSE. IN NO EVENT WILL ANY OF THE AUTHORS OR COPYRIGHT HOLDERS + BE LIABLE FOR ANY DAMAGES CAUSED BY THE USE OR THE INABILITY TO + USE, OF THE FREETYPE PROJECT. + +2. Redistribution +----------------- + + This license grants a worldwide, royalty-free, perpetual and + irrevocable right and license to use, execute, perform, compile, + display, copy, create derivative works of, distribute and + sublicense the FreeType Project (in both source and object code + forms) and derivative works thereof for any purpose; and to + authorize others to exercise some or all of the rights granted + herein, subject to the following conditions: + + o Redistribution of source code must retain this license file + (`FTL.TXT') unaltered; any additions, deletions or changes to + the original files must be clearly indicated in accompanying + documentation. The copyright notices of the unaltered, + original files must be preserved in all copies of source + files. + + o Redistribution in binary form must provide a disclaimer that + states that the software is based in part of the work of the + FreeType Team, in the distribution documentation. We also + encourage you to put an URL to the FreeType web page in your + documentation, though this isn't mandatory. + + These conditions apply to any software derived from or based on + the FreeType Project, not just the unmodified files. If you use + our work, you must acknowledge us. However, no fee need be paid + to us. + +3. Advertising +-------------- + + Neither the FreeType authors and contributors nor you shall use + the name of the other for commercial, advertising, or promotional + purposes without specific prior written permission. + + We suggest, but do not require, that you use one or more of the + following phrases to refer to this software in your documentation + or advertising materials: `FreeType Project', `FreeType Engine', + `FreeType library', or `FreeType Distribution'. + + As you have not signed this license, you are not required to + accept it. However, as the FreeType Project is copyrighted + material, only this license, or another one contracted with the + authors, grants you the right to use, distribute, and modify it. + Therefore, by using, distributing, or modifying the FreeType + Project, you indicate that you understand and accept all the terms + of this license. + +4. Contacts +----------- + + There are two mailing lists related to FreeType: + + o freetype@nongnu.org + + Discusses general use and applications of FreeType, as well as + future and wanted additions to the library and distribution. + If you are looking for support, start in this list if you + haven't found anything to help you in the documentation. + + o freetype-devel@nongnu.org + + Discusses bugs, as well as engine internals, design issues, + specific licenses, porting, etc. + + Our home page can be found at + + http://www.freetype.org + + +--- end of FTL.TXT --- + diff --git a/meta/files/common-licenses/GPL-2.0-with-GCC-exception b/meta/files/common-licenses/GPL-2.0-with-GCC-exception index 5d0beb8efa..ff8de09dc7 100644 --- a/meta/files/common-licenses/GPL-2.0-with-GCC-exception +++ b/meta/files/common-licenses/GPL-2.0-with-GCC-exception @@ -2,5 +2,16 @@ insert GPL v2 text here GCC Linking Exception -In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable.) +In addition to the permissions in the GNU General Public License, the Free +Software Foundation gives you unlimited permission to link the compiled version +of this file into combinations with other programs, and to distribute those +combinations without any restriction coming from the use of this file. (The +General Public License restrictions do apply in other respects; for example, +they cover modification of the file, and distribution when not linked into a +combine executable.) + + + + + diff --git a/meta/files/common-licenses/GPL-2.0-with-OpenSSL-exception b/meta/files/common-licenses/GPL-2.0-with-OpenSSL-exception new file mode 100644 index 0000000000..7586c6225f --- /dev/null +++ b/meta/files/common-licenses/GPL-2.0-with-OpenSSL-exception @@ -0,0 +1,285 @@ + +GNU GENERAL PUBLIC LICENSE + +Version 2, June 1991 + +Copyright (C) 1989, 1991 Free Software Foundation, Inc. +51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA + +Everyone is permitted to copy and distribute verbatim copies +of this license document, but changing it is not allowed. +Preamble + +The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation`s software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too. + +When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. + +To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. + +For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. + +We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. + +Also, for each author`s protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors` reputations. + +Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone`s free use or not licensed at all. + +The precise terms and conditions for copying, distribution and modification follow. + +TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + +0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. + +1. You may copy and distribute verbatim copies of the Program`s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. + +You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. + +2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: + +a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. +b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. +c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) +These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. + +3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: + +a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, +b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, +c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) +The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. + +If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. + +4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. + +5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. + +6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients` exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. + +7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. + +It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. + +This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. + +8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. + +9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. + +Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. + +10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. + +NO WARRANTY + +11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + +12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. + +END OF TERMS AND CONDITIONS + +How to Apply These Terms to Your New Programs + +If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. + +To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. + +one line to give the program`s name and an idea of what it does. +Copyright (C) yyyy name of author + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this when it starts in an interactive mode: + +Gnomovision version 69, Copyright (C) year name of author +Gnomovision comes with ABSOLUTELY NO WARRANTY; for details +type `show w`. This is free software, and you are welcome +to redistribute it under certain conditions; type `show c` +for details. +The hypothetical commands `show w` and `show c` should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w` and `show c`; they could even be mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: + +Yoyodyne, Inc., hereby disclaims all copyright +interest in the program `Gnomovision` +(which makes passes at compilers) written +by James Hacker. + +signature of Ty Coon, 1 April 1989 +Ty Coon, President of Vice +This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. + + +In addition, as a special exception, the copyright holder +gives permission to link the code of this program with +any version of the OpenSSL library which is distributed +under a license identical to that listed in the included +COPYING.OpenSSL file, and distribute linked combinations +including the two. You must obey the GNU General Public +License in all respects for all of the code used other +than OpenSSL. If you modify this file, you may extend this +exception to your version of the file, but you are not +obligated to do so. If you do not wish to do so, delete +this exception statement from your version. + + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation, version 2 of the License + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + LICENSE ISSUES + ============== + + The OpenSSL toolkit stays under a dual license, i.e. both the conditions of + the OpenSSL License and the original SSLeay license apply to the toolkit. + See below for the actual license texts. Actually both licenses are BSD-style + Open Source licenses. In case of any license issues related to OpenSSL + please contact openssl-core@openssl.org. + + OpenSSL License + --------------- + +/* ==================================================================== + * Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * + * 3. All advertising materials mentioning features or use of this + * software must display the following acknowledgment: + * "This product includes software developed by the OpenSSL Project + * for use in the OpenSSL Toolkit. (http://www.openssl.org/)" + * + * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to + * endorse or promote products derived from this software without + * prior written permission. For written permission, please contact + * openssl-core@openssl.org. + * + * 5. Products derived from this software may not be called "OpenSSL" + * nor may "OpenSSL" appear in their names without prior written + * permission of the OpenSSL Project. + * + * 6. Redistributions of any form whatsoever must retain the following + * acknowledgment: + * "This product includes software developed by the OpenSSL Project + * for use in the OpenSSL Toolkit (http://www.openssl.org/)" + * + * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY + * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * ==================================================================== + * + * This product includes cryptographic software written by Eric Young + * (eay@cryptsoft.com). This product includes software written by Tim + * Hudson (tjh@cryptsoft.com). + * + */ + + Original SSLeay License + ----------------------- + +/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) + * All rights reserved. + * + * This package is an SSL implementation written + * by Eric Young (eay@cryptsoft.com). + * The implementation was written so as to conform with Netscapes SSL. + * + * This library is free for commercial and non-commercial use as long as + * the following conditions are aheared to. The following conditions + * apply to all code found in this distribution, be it the RC4, RSA, + * lhash, DES, etc., code; not just the SSL code. The SSL documentation + * included with this distribution is covered by the same copyright terms + * except that the holder is Tim Hudson (tjh@cryptsoft.com). + * + * Copyright remains Eric Young's, and as such any Copyright notices in + * the code are not to be removed. + * If this package is used in a product, Eric Young should be given attribution + * as the author of the parts of the library used. + * This can be in the form of a textual message at program startup or + * in documentation (online or textual) provided with the package. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * "This product includes cryptographic software written by + * Eric Young (eay@cryptsoft.com)" + * The word 'cryptographic' can be left out if the rouines from the library + * being used are not cryptographic related :-). + * 4. If you include any Windows specific code (or a derivative thereof) from + * the apps directory (application code) you must include an acknowledgement: + * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)" + * + * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * The licence and distribution terms for any publically available version or + * derivative of this code cannot be changed. i.e. this code cannot simply be + * copied and put under another distribution licence + * [including the GNU Public Licence.] + */ diff --git a/meta/files/common-licenses/GPL-2.0-with-font-exception b/meta/files/common-licenses/GPL-2.0-with-font-exception index 99b84e0b38..abb42f9f97 100644 --- a/meta/files/common-licenses/GPL-2.0-with-font-exception +++ b/meta/files/common-licenses/GPL-2.0-with-font-exception @@ -2,5 +2,17 @@ insert GPL v2 text here Font Exception -As a special exception, if you create a document which uses this font, and embed this font or unaltered portions of this font into the document, this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify this font, you may extend this exception to your version of the font, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. +As a special exception, if you create a document which uses this font, and +embed this font or unaltered portions of this font into the document, this font +does not by itself cause the resulting document to be covered by the GNU +General Public License. This exception does not however invalidate any other +reasons why the document might be covered by the GNU General Public License. If +you modify this font, you may extend this exception to your version of the +font, but you are not obligated to do so. If you do not wish to do so, delete +this exception statement from your version. + + + + + diff --git a/meta/files/common-licenses/GPL-3.0 b/meta/files/common-licenses/GPL-3.0 index 3e0e94d653..e0665a64a8 100644 --- a/meta/files/common-licenses/GPL-3.0 +++ b/meta/files/common-licenses/GPL-3.0 @@ -1,3 +1,225 @@ +GNU GENERAL PUBLIC LICENSE -license exceeds allowable cell character limit +Version 3, 29 June 2007 +Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/> + +Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. +Preamble + +The GNU General Public License is a free, copyleft license for software and other kinds of works. + +The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too. + +When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. + +To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. + +For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. + +Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it. + +For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions. + +Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users. + +Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. + +The precise terms and conditions for copying, distribution and modification follow. +TERMS AND CONDITIONS +0. Definitions. + +“This License” refers to version 3 of the GNU General Public License. + +“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. + +“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations. + +To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work. + +A “covered work” means either the unmodified Program or a work based on the Program. + +To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. + +To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. + +An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. +1. Source Code. + +The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work. + +A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. + +The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. + +The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. + +The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. + +The Corresponding Source for a work in source code form is that same work. +2. Basic Permissions. + +All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. + +You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. + +Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary. +3. Protecting Users' Legal Rights From Anti-Circumvention Law. + +No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. + +When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures. +4. Conveying Verbatim Copies. + +You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program. + +You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. +5. Conveying Modified Source Versions. + +You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: + + * a) The work must carry prominent notices stating that you modified it, and giving a relevant date. + * b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”. + * c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. + * d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. + +A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. +6. Conveying Non-Source Forms. + +You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: + + * a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. + * b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. + * c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. + * d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. + * e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. + +A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. + +A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product. + +“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made. + +If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). + +The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. + +Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying. +7. Additional Terms. + +“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions. + +When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. + +Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: + + * a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or + * b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or + * c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or + * d) Limiting the use for publicity purposes of names of licensors or authors of the material; or + * e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or + * f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors. + +All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying. + +If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. + +Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. +8. Termination. + +You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). + +However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. + +Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. + +Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10. +9. Acceptance Not Required for Having Copies. + +You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. +10. Automatic Licensing of Downstream Recipients. + +Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. + +An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts. + +You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it. +11. Patents. + +A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's “contributor version”. + +A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License. + +Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version. + +In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party. + +If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. + +If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it. + +A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007. + +Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. +12. No Surrender of Others' Freedom. + +If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program. +13. Use with the GNU Affero General Public License. + +Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. +14. Revised Versions of this License. + +The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. + +Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. + +If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program. + +Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version. +15. Disclaimer of Warranty. + +THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. +16. Limitation of Liability. + +IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. +17. Interpretation of Sections 15 and 16. + +If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. + +END OF TERMS AND CONDITIONS +How to Apply These Terms to Your New Programs + +If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. + +To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found. + + <one line to give the program's name and a brief idea of what it does.> + Copyright (C) <year> <name of author> + + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. + +Also add information on how to contact you by electronic and paper mail. + +If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode: + + <program> Copyright (C) <year> <name of author> + This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”. + +You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>. + +The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>. diff --git a/meta/files/common-licenses/ICU b/meta/files/common-licenses/ICU new file mode 100644 index 0000000000..a29b6fb509 --- /dev/null +++ b/meta/files/common-licenses/ICU @@ -0,0 +1,13 @@ +COPYRIGHT AND PERMISSION NOTICE + +Copyright (c) 1995-2012 International Business Machines Corporation and others + +All rights reserved. + +Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + +Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. + +All trademarks and registered trademarks mentioned herein are the property of their respective owners. diff --git a/meta/files/common-licenses/LGPL-2.0 b/meta/files/common-licenses/LGPL-2.0 index d210148d17..5931d439b4 100644 --- a/meta/files/common-licenses/LGPL-2.0 +++ b/meta/files/common-licenses/LGPL-2.0 @@ -1,173 +1,342 @@ - GNU LIBRARY GENERAL PUBLIC LICENSE + + Version 2, June 1991 + + Copyright (C) 1991 Free Software Foundation, Inc. + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + [This is the first released version of the library GPL. It is + numbered 2 because it goes with version 2 of the ordinary GPL.] + Preamble + + The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. + + This license, the Library General Public License, applies to some specially designated Free Software Foundation software, and to any other libraries whose authors decide to use it. You can use it for your libraries, too. + + When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library, or if you modify it. + + For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights. + + Our method of protecting your rights has two steps: (1) copyright the library, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the library. -Also, for each distributor`s protection, we want to make certain that everyone understands that there is no warranty for this free library. If the library is modified by someone else and passed on, we want its recipients to know that what they have is not the original version, so that any problems introduced by others will not reflect on the original authors` reputations. -Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that companies distributing free software will individually obtain patent licenses, thus in effect transforming the program into proprietary software. To prevent this, we have made it clear that any patent must be licensed for everyone`s free use or not licensed at all. -Most GNU software, including some libraries, is covered by the ordinary GNU General Public License, which was designed for utility programs. This license, the GNU Library General Public License, applies to certain designated libraries. This license is quite different from the ordinary one; be sure to read it in full, and don`t assume that anything in it is the same as in the ordinary license. +Also, for each distributor's protection, we want to make certain that everyone understands that there is no warranty for this free library. If the library is modified by someone else and passed on, we want its recipients to know that what they have is not the original version, so that any problems introduced by others will not reflect on the original authors' reputations. + + + +Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that companies distributing free software will individually obtain patent licenses, thus in effect transforming the program into proprietary software. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. + + + +Most GNU software, including some libraries, is covered by the ordinary GNU General Public License, which was designed for utility programs. This license, the GNU Library General Public License, applies to certain designated libraries. This license is quite different from the ordinary one; be sure to read it in full, and don't assume that anything in it is the same as in the ordinary license. + + The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such. + + Because of this blurred distinction, using the ordinary General Public License for libraries did not effectively promote software sharing, because most developers did not use the libraries. We concluded that weaker conditions might promote sharing better. + + However, unrestricted linking of non-free programs would deprive the users of those programs of all benefit from the free status of the libraries themselves. This Library General Public License is intended to permit developers of non-free programs to use free libraries, while preserving your freedom as a user of such programs to change the free libraries that are incorporated in them. (We have not seen how to achieve this as regards changes in header files, but we have achieved it as regards changes in the actual functions of the Library.) The hope is that this will lead to faster development of free libraries. + + The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, while the latter only works together with the library. + + Note that it is possible for a library to be covered by the ordinary General Public License rather than by this special one. + + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License Agreement applies to any software library which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Library General Public License (also called "this License"). Each licensee is addressed as "you". + + A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. + + The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) + + "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. + + Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. -1. You may copy and distribute verbatim copies of the Library`s complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. + + +1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. + + You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: + + a) The modified work must itself be a software library. + b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. + c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. + d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. + (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) + + These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. + + Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. + + In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. + + 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. + + Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. + + This option is useful when you wish to copy part of the code of the Library into a program that is not a library. + + 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. + + If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. + + 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. + + However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. + + When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. + + If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) + + Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. -6. As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer`s own use and reverse engineering for debugging such modifications. + + +6. As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. + + You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: + + a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) + b) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. + c) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. + d) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. + For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. + + It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. + + 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: + + a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. + b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. + 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. + + 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. -10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients` exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. + + +10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. + + 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. + + If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. + + It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. + + This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. + + 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. + + 13. The Free Software Foundation may publish revised and/or new versions of the Library General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. + + Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. + + 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Libraries + + If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). + + To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. -one line to give the library`s name and an idea of what it does. + + +one line to give the library's name and an idea of what it does. + Copyright (C) year name of author + + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + + This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with this library; if not, write to the + Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, + Boston, MA 02110-1301, USA. + Also add information on how to contact you by electronic and paper mail. + + You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in -the library `Frob` (a library for tweaking knobs) written + +the library `Frob' (a library for tweaking knobs) written + by James Random Hacker. + + signature of Ty Coon, 1 April 1990 + Ty Coon, President of Vice -That`s all there is to it! + +That's all there is to it! diff --git a/meta/files/common-licenses/LGPL-3.0 b/meta/files/common-licenses/LGPL-3.0 index f0790a86b1..6be29bf206 100644 --- a/meta/files/common-licenses/LGPL-3.0 +++ b/meta/files/common-licenses/LGPL-3.0 @@ -1,66 +1,65 @@ - GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007 -Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/> +Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below. - 0. Additional Definitions. -As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License. - -“The Library” refers to a covered work governed by this License, other than an Application or a Combined Work as defined below. +As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License. -An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library. +“The Library” refers to a covered work governed by this License, other than an Application or a Combined Work as defined below. -A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”. +An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library. -The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version. +A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”. -The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work. +The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version. +The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work. 1. Exception to Section 3 of the GNU GPL. You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL. - 2. Conveying Modified Versions. If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version: -a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or -b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy. + * a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or + * b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy. + 3. Object Code Incorporating Material from Library Header Files. The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following: -a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. -b) Accompany the object code with a copy of the GNU GPL and this license document. + * a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. + * b) Accompany the object code with a copy of the GNU GPL and this license document. + 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: -a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. -b) Accompany the Combined Work with a copy of the GNU GPL and this license document. -c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document. -d) Do one of the following: -0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. -1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user`s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. -e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.) + * a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. + * b) Accompany the Combined Work with a copy of the GNU GPL and this license document. + * c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document. + * d) Do one of the following: + o 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. + o 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. + * e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.) + 5. Combined Libraries. You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following: -a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. -b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. + * a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. + * b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. + 6. Revised Versions of the GNU Lesser General Public License. The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. -Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation. - -If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy`s public statement of acceptance of any version is permanent authorization for you to choose that version for the Library. +Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation. +If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy's public statement of acceptance of any version is permanent authorization for you to choose that version for the Library. diff --git a/meta/files/common-licenses/OASIS b/meta/files/common-licenses/OASIS new file mode 100644 index 0000000000..f93df7af27 --- /dev/null +++ b/meta/files/common-licenses/OASIS @@ -0,0 +1,13 @@ + Permission to use, copy, modify and distribute the DocBook DTD and + its accompanying documentation for any purpose and without fee is + hereby granted in perpetuity, provided that the above copyright + notice and this paragraph appear in all copies. The copyright + holders make no representation about the suitability of the DTD for + any purpose. It is provided "as is" without expressed or implied + warranty. + + If you modify the DocBook DTD in any way, except for declaring and + referencing additional sets of general entities and declaring + additional notations, label your DTD as a variant of DocBook. See + the maintenance documentation for more information. + diff --git a/meta/files/common-licenses/OSL-1.0 b/meta/files/common-licenses/OSL-1.0 index 019f576b00..85ad0dadb1 100644 --- a/meta/files/common-licenses/OSL-1.0 +++ b/meta/files/common-licenses/OSL-1.0 @@ -1,5 +1,5 @@ -he Open Software License +The Open Software License v. 1.0 This Open Software License (the "License") applies to any original diff --git a/meta/files/common-licenses/Proprietary b/meta/files/common-licenses/Proprietary new file mode 100644 index 0000000000..661875810d --- /dev/null +++ b/meta/files/common-licenses/Proprietary @@ -0,0 +1 @@ +Proprietary license. diff --git a/meta/files/common-licenses/UCB b/meta/files/common-licenses/UCB new file mode 100644 index 0000000000..79a757af95 --- /dev/null +++ b/meta/files/common-licenses/UCB @@ -0,0 +1,26 @@ + Copyright (c) 1987, 1989, 1990, 1991, 1992, 1993, 1994 + The Regents of the University of California. All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions + are met: + 1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + 2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + 3. Neither the name of the University nor the names of its contributors + may be used to endorse or promote products derived from this software + without specific prior written permission. + + THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + SUCH DAMAGE. diff --git a/meta/files/device_table-minimal.txt b/meta/files/device_table-minimal.txt index 495b5d5635..c6e54631ce 100644 --- a/meta/files/device_table-minimal.txt +++ b/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 diff --git a/meta/lib/oe/data.py b/meta/lib/oe/data.py index 4b4d03eaa4..af900be6e4 100644 --- a/meta/lib/oe/data.py +++ b/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))) diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py index 1406e1950c..9768be077f 100644 --- a/meta/lib/oe/patch.py +++ b/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 diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py index 1455e8e719..43639d5ddd 100644 --- a/meta/lib/oe/terminal.py +++ b/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 diff --git a/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb b/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb index e80e108ca5..bf53cc650a 100644 --- a/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb +++ b/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() { diff --git a/meta/recipes-bsp/grub/grub_1.99.bb b/meta/recipes-bsp/grub/grub_1.99.bb index b910b5a4a0..0c8648e462 100644 --- a/meta/recipes-bsp/grub/grub_1.99.bb +++ b/meta/recipes-bsp/grub/grub_1.99.bb @@ -19,6 +19,9 @@ SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \ file://grub-install.in.patch;apply=yes \ file://40_custom" +SRC_URI[md5sum] = "ca9f2a2d571b57fc5c53212d1d22e2b5" +SRC_URI[sha256sum] = "b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff" + inherit autotools inherit gettext @@ -41,4 +44,4 @@ do_install_append () { FILES_${PN}-doc = "${datadir}" FILES_${PN} = "/usr /etc" - +INSANE_SKIP_${PN} = "arch" diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc index c3c9c71985..1d67c4ed0a 100644 --- a/meta/recipes-connectivity/avahi/avahi.inc +++ b/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` diff --git a/meta/recipes-connectivity/connman/connman.inc b/meta/recipes-connectivity/connman/connman.inc index a72c34a183..b6c1330be4 100644 --- a/meta/recipes-connectivity/connman/connman.inc +++ b/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/ diff --git a/meta/recipes-connectivity/connman/connman_0.75.bb b/meta/recipes-connectivity/connman/connman_0.75.bb index 5a7b28429a..5c5472da7f 100644 --- a/meta/recipes-connectivity/connman/connman_0.75.bb +++ b/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 \ diff --git a/meta/recipes-connectivity/gypsy/gypsy_0.8.bb b/meta/recipes-connectivity/gypsy/gypsy_0.8.bb index f3d3fa7c28..59a34fa66d 100644 --- a/meta/recipes-connectivity/gypsy/gypsy_0.8.bb +++ b/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" diff --git a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb index 5f614f86a2..87707142d5 100644 --- a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb +++ b/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 } } diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bb b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bb index 08468fe2d7..e8b0490b8c 100644 --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bb +++ b/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" diff --git a/meta/recipes-connectivity/openssh/openssh_5.8p2.bb b/meta/recipes-connectivity/openssh/openssh_5.8p2.bb index 030a83b91f..5f5f0bc396 100644 --- a/meta/recipes-connectivity/openssh/openssh_5.8p2.bb +++ b/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" diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/configure-targets.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/configure-targets.patch index 2317949a87..2317949a87 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/configure-targets.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/configure-targets.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/ca.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/ca.patch index aba4d42983..aba4d42983 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/ca.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/ca.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/config-hurd.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/config-hurd.patch index 2359d158d1..2359d158d1 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/config-hurd.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/config-hurd.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/debian-targets.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/debian-targets.patch index 5720988a08..5720988a08 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/debian-targets.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/debian-targets.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/engines-path.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/engines-path.patch index 5b4c7d5f77..5b4c7d5f77 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/engines-path.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/engines-path.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/kfreebsd-pipe.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/kfreebsd-pipe.patch index b0312f3bf1..b0312f3bf1 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/kfreebsd-pipe.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/kfreebsd-pipe.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/make-targets.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/make-targets.patch index 91207d8454..91207d8454 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/make-targets.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/make-targets.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-dir.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-dir.patch index 358f8cd8a1..358f8cd8a1 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-dir.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-dir.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-section.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-section.patch index b74b12e752..b74b12e752 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-section.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-section.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-rpath.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-rpath.patch index 53b761442b..53b761442b 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-rpath.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-rpath.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-symbolic.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-symbolic.patch index 87eadaccc5..87eadaccc5 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-symbolic.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-symbolic.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/perl-path.diff b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/perl-path.diff index ced45a338d..ced45a338d 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/perl-path.diff +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/perl-path.diff diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pic.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pic.patch index 5fc8f658f0..5fc8f658f0 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pic.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pic.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pkg-config.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pkg-config.patch index 46c6f03e3d..46c6f03e3d 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pkg-config.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pkg-config.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rc4-amd64.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rc4-amd64.patch index f57fbc9352..f57fbc9352 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rc4-amd64.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rc4-amd64.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash-crt.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash-crt.patch index d9d6b70b30..d9d6b70b30 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash-crt.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash-crt.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash_pod.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash_pod.patch index 3426ba8168..3426ba8168 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash_pod.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash_pod.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/series b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/series index b764c0414d..b764c0414d 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/series +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/series diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/shared-lib-ext.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/shared-lib-ext.patch index 79eb39f79b..79eb39f79b 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/shared-lib-ext.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/shared-lib-ext.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/stddef.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/stddef.patch index 3436b29937..3436b29937 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/stddef.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/stddef.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/version-script.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/version-script.patch index 6fa3d75d4b..6fa3d75d4b 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/version-script.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/version-script.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/parallel-make-fix.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/parallel-make-fix.patch index 82857f5744..82857f5744 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/parallel-make-fix.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/parallel-make-fix.patch diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/shared-libs.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/shared-libs.patch index 19de11243a..19de11243a 100644 --- a/meta/recipes-connectivity/openssl/openssl-0.9.8r/shared-libs.patch +++ b/meta/recipes-connectivity/openssl/openssl-0.9.8s/shared-libs.patch diff --git a/meta/recipes-connectivity/openssl/openssl.inc b/meta/recipes-connectivity/openssl/openssl.inc index 88d5081495..f3ada138ac 100644 --- a/meta/recipes-connectivity/openssl/openssl.inc +++ b/meta/recipes-connectivity/openssl/openssl.inc @@ -112,4 +112,5 @@ do_install () { chmod 644 ${D}${libdir}/pkgconfig/openssl.pc oe_libinstall -so libcrypto ${D}${libdir} oe_libinstall -so libssl ${D}${libdir} + sed -i -e '1s,.*,#!${bindir}/env perl,' ${D}${libdir}/ssl/misc/CA.pl } diff --git a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb b/meta/recipes-connectivity/openssl/openssl_0.9.8s.bb index 54bdcc2f14..a2d2d2cd85 100644 --- a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb +++ b/meta/recipes-connectivity/openssl/openssl_0.9.8s.bb @@ -1,6 +1,6 @@ require openssl.inc -PR = "r5" +PR = "r0" SRC_URI += "file://debian/ca.patch \ file://debian/config-hurd.patch;apply=no \ file://debian/debian-targets.patch \ @@ -21,10 +21,10 @@ SRC_URI += "file://debian/ca.patch \ file://debian/version-script.patch \ file://debian/perl-path.diff" -SRC_URI[md5sum] = "0352932ea863bc02b056cda7c9ac5b79" -SRC_URI[sha256sum] = "42b2368f786b05ed3be846838dce126b4e8e3dba8fb2e0ce83102df28c102fad" - SRC_URI += "file://configure-targets.patch \ file://shared-libs.patch" +SRC_URI[md5sum] = "fbf71e8e050bc1ec290b7468bab1a76e" +SRC_URI[sha256sum] = "edc9639beaf2d5e239d8e5c9d2fe1959e6726a5d7f8ab8430613835f4623f9ba" + BBCLASSEXTEND = "native nativesdk" diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb index 94231e0af6..8e0b215de3 100644 --- a/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb +++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb @@ -9,15 +9,16 @@ LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b" AUTHOR = "Thomas Hood" HOMEPAGE = "http://packages.debian.org/resolvconf" -DEPENDS = "bash" RDEPENDS_${PN} = "bash" -PR = "r0" +PR = "r1" SRC_URI = "${DEBIAN_MIRROR}/main/r/resolvconf/resolvconf_${PV}.tar.gz" SRC_URI[md5sum] = "59b20258bb8a3c25b8c4083fc0279547" SRC_URI[sha256sum] = "37691677cea24da66d6664c98668b5f16667c0133f17feb166f246ee923ad756" +inherit allarch + do_compile () { : } @@ -31,6 +32,3 @@ do_install () { install -m 0644 README ${D}${docdir}/${P}/ install -m 0644 man/resolvconf.8 ${D}${mandir}/man8/ } - -PACKAGE_ARCH = "all" - diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc index cd62d8f7e9..ccdc4c3e7e 100644 --- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc +++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc @@ -66,9 +66,9 @@ do_install () { } pkg_postinst_wpa-supplicant () { - # can't do this offline + # If we're offline, we don't need to do this. if [ "x$D" != "x" ]; then - exit 1 + exit 0 fi DBUSPID=`pidof dbus-daemon` diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bb b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bb index 03bd937890..98eba77de7 100644 --- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bb +++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bb @@ -1,6 +1,6 @@ require wpa-supplicant-0.7.inc -PR = "r4" +PR = "r5" SRC_URI[md5sum] = "f516f191384a9a546e3f5145c08addda" SRC_URI[sha256sum] = "d0cd50caa85346ccc376dcda5ed3c258eef19a93b3cade39d25760118ad59443" diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb b/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb index 137512dc3c..5feb924214 100644 --- a/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb +++ b/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb @@ -1,7 +1,7 @@ SUMMARY = "Base system master password/group files." DESCRIPTION = "The master copies of the user database files (/etc/passwd and /etc/group). The update-passwd tool is also provided to keep the system databases synchronized with these master files." SECTION = "base" -PR = "r3" +PR = "r9" LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a" @@ -16,6 +16,11 @@ S = "${WORKDIR}/base-passwd" inherit autotools +PACKAGES =+ "${PN}-update" +FILES_${PN}-update = "${sbindir}/* ${datadir}/${PN}" + +ALLOW_EMPTY_${PN} = "1" + SSTATEPOSTINSTFUNCS += "base_passwd_sstate_postinst" do_install () { @@ -37,19 +42,6 @@ do_install () { install -p -m 644 debian/copyright ${D}${docdir}/${BPN}/ } -pkg_postinst_${PN} () { - set -e - - if [ ! -e $D${sysconfdir}/passwd ] ; then - cp $D${datadir}/base-passwd/passwd.master $D${sysconfdir}/passwd - fi - - if [ ! -e $D${sysconfdir}/group ] ; then - cp $D${datadir}/base-passwd/group.master $D${sysconfdir}/group - fi - exit 0 -} - base_passwd_sstate_postinst() { if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] then @@ -63,3 +55,38 @@ base_passwd_sstate_postinst() { install -p -m 644 ${STAGING_DIR_TARGET}${datadir}/base-passwd/group.master ${STAGING_DIR_TARGET}${sysconfdir}/group fi } + +python populate_packages_prepend() { + # Add in the preinst function for ${PN} + # We have to do this here as prior to this, passwd/group.master + # would be unavailable. We need to create these files at preinst + # time before the files from the package may be available, hence + # storing the data from the files in the preinst directly. + + f = open(bb.data.expand("${STAGING_DATADIR}/base-passwd/passwd.master", d), 'r') + passwd = "".join(f.readlines()) + f.close() + f = open(bb.data.expand("${STAGING_DATADIR}/base-passwd/group.master", d), 'r') + group = "".join(f.readlines()) + f.close() + + preinst = """#!/bin/sh +if [ ! -e $D${sysconfdir}/passwd ]; then + cat << EOF > $D${sysconfdir}/passwd +""" + passwd + """EOF +fi +if [ ! -e $D${sysconfdir}/group ]; then + cat << EOF > $D${sysconfdir}/group +""" + group + """EOF +fi +""" + d.setVar('pkg_preinst_${PN}', preinst) +} + +pkg_postinst_${PN}-update () { +#!/bin/sh +if [ -n "$D" ]; then + exit 0 +fi +${sbindir}/update-passwd +} diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc index acd635b1e3..f8fee51725 100644 --- a/meta/recipes-core/busybox/busybox.inc +++ b/meta/recipes-core/busybox/busybox.inc @@ -270,6 +270,7 @@ pkg_prerm_${PN} () { ln -s /bin/busybox $tmpdir/rm ln -s /bin/busybox $tmpdir/sed ln -s /bin/busybox $tmpdir/sort + ln -s /bin/busybox $tmpdir/grep export PATH=$PATH:$tmpdir while read link diff --git a/meta/recipes-core/busybox/busybox_1.18.5.bb b/meta/recipes-core/busybox/busybox_1.18.5.bb index bdafb316a5..17d583e6e3 100644 --- a/meta/recipes-core/busybox/busybox_1.18.5.bb +++ b/meta/recipes-core/busybox/busybox_1.18.5.bb @@ -1,5 +1,5 @@ require busybox.inc -PR = "r1" +PR = "r2" SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \ file://udhcpscript.patch \ diff --git a/meta/recipes-core/coreutils/coreutils_8.12.bb b/meta/recipes-core/coreutils/coreutils_8.12.bb index 0004ce7fc8..ebf1344f5b 100644 --- a/meta/recipes-core/coreutils/coreutils_8.12.bb +++ b/meta/recipes-core/coreutils/coreutils_8.12.bb @@ -7,8 +7,8 @@ BUGTRACKER = "http://debbugs.gnu.org/coreutils" LICENSE = "GPLv3+" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\ file://src/ls.c;startline=5;endline=16;md5=e1a509558876db58fb6667ba140137ad" -PR = "r3" -DEPENDS = "gmp" +PR = "r4" +DEPENDS = "gmp libcap" DEPENDS_virtclass-native = "" inherit autotools gettext @@ -28,7 +28,7 @@ bindir_progs = "base64 basename chcon cksum comm csplit cut dir dircolors dirnam join link logname md5sum mkfifo mktemp nice nl nohup nproc od paste pathchk \ pinky pr printenv printf ptx readlink runcon seq sha1sum sha224sum sha256sum \ sha384sum sha512sum shred shuf sort split stat stdbuf sum tac tail tee test timeout\ - tr truncate tsort tty unexpand uniq unlink uptime users vdir wc who whoami yes" + tr truncate tsort tty unexpand uniq unlink uptime users vdir wc who whoami yes df" # hostname gets a special treatment and is not included in this base_bindir_progs = "cat chgrp chmod chown cp date dd echo false kill ln ls mkdir \ diff --git a/meta/recipes-core/dbus/dbus-glib.inc b/meta/recipes-core/dbus/dbus-glib.inc index 704dc04cd0..80f68c8c19 100644 --- a/meta/recipes-core/dbus/dbus-glib.inc +++ b/meta/recipes-core/dbus/dbus-glib.inc @@ -19,7 +19,9 @@ EXTRA_OECONF = "--with-introspect-xml=${STAGING_DATADIR_NATIVE}/dbus/dbus-bus-in --with-dbus-binding-tool=${STAGING_BINDIR_NATIVE}/dbus-binding-tool" EXTRA_OECONF_virtclass-native = "--with-introspect-xml=${STAGING_DATADIR_NATIVE}/dbus/dbus-bus-introspect.xml" -FILES_${PN} = "${libdir}/lib*.so.*" +FILES_${PN} = "${libdir}/lib*${SOLIBS}" +FILES_${PN}-bash_completion = "${sysconfdir}/bash_completion.d/dbus-bash-completion.sh \ + ${libexecdir}/dbus-bash-completion-helper" FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool" FILES_${PN}-dev += "${bindir}/dbus-binding-tool" diff --git a/meta/recipes-core/dbus/dbus-glib_0.92.bb b/meta/recipes-core/dbus/dbus-glib_0.92.bb index 72bea89825..c7266d4aa8 100644 --- a/meta/recipes-core/dbus/dbus-glib_0.92.bb +++ b/meta/recipes-core/dbus/dbus-glib_0.92.bb @@ -1,6 +1,6 @@ require dbus-glib.inc -PR = "r0" +PR = "r1" SRC_URI[md5sum] = "b595b36890c4f9f8f5d5dec131c495f8" SRC_URI[sha256sum] = "5a7fd4cf937cdcb7f2eed61341b70ee0f2607450a50db381618598adf60dd40e" diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc index a8ecda8d4f..9ea42c27cb 100644 --- a/meta/recipes-core/dbus/dbus.inc +++ b/meta/recipes-core/dbus/dbus.inc @@ -14,11 +14,17 @@ SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \ file://tmpdir.patch; \ file://dbus-1.init" -inherit autotools pkgconfig gettext update-rc.d +inherit useradd autotools pkgconfig gettext update-rc.d INITSCRIPT_NAME = "dbus-1" INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ." +USERADD_PACKAGES = "${PN}" +GROUPADD_PARAM_${PN} = "-r netdev" +USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \ + --no-create-home --shell /bin/false \ + --user-group messagebus" + CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session.conf" DEBIANNAME_${PN} = "dbus-1" @@ -37,6 +43,7 @@ FILES_${PN} = "${bindir}/dbus-daemon* \ ${bindir}/dbus-monitor \ ${libexecdir}/dbus* \ ${sysconfdir} \ + ${localstatedir} \ ${datadir}/dbus-1/services \ ${datadir}/dbus-1/system-services" FILES_${PN}-lib = "${libdir}/lib*.so.*" @@ -44,32 +51,7 @@ RRECOMMENDS_${PN}-lib = "${PN}" FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool" pkg_postinst_dbus() { - # can't do adduser stuff offline - if [ "x$D" != "x" ]; then - exit 1 - fi - - MESSAGEUSER=messagebus - MESSAGEHOME=/var/run/dbus - UUIDDIR=/var/lib/dbus - - mkdir -p $MESSAGEHOME - mkdir -p $UUIDDIR - chgrp "$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || addgroup "$MESSAGEUSER" - chown "$MESSAGEUSER":"$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || \ - adduser --system --home "$MESSAGEHOME" --no-create-home --disabled-password \ - --ingroup "$MESSAGEUSER" "$MESSAGEUSER" - - chown "$MESSAGEUSER":"$MESSAGEUSER" "$UUIDDIR" - - grep -q netdev: /etc/group || addgroup netdev - - chown root:"$MESSAGEUSER" /usr/libexec/dbus-daemon-launch-helper - chmod 4754 /usr/libexec/dbus-daemon-launch-helper - - # add volatile after new user/grp are created - echo "d messagebus messagebus 0755 /var/run/dbus none" > /etc/default/volatiles/99_dbus - if [ -e /etc/init.d/populate-volatile.sh ] ; then + if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then /etc/init.d/populate-volatile.sh update fi } @@ -92,6 +74,18 @@ do_install() { install -d ${D}${sysconfdir}/init.d install -m 0755 ${WORKDIR}/dbus-1.init ${D}${sysconfdir}/init.d/dbus-1 + install -d ${D}${sysconfdir}/default/volatiles + echo "d messagebus messagebus 0755 ${localstatedir}/run/dbus none" \ + > ${D}${sysconfdir}/default/volatiles/99_dbus + + + mkdir -p ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus + + chown messagebus:messagebus ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus + + chown root:messagebus ${D}${libexecdir}/dbus-daemon-launch-helper + chmod 4754 ${D}${libexecdir}/dbus-daemon-launch-helper + # disable dbus-1 sysv script on systemd installs # nearly all distros call the initscript plain 'dbus', but OE-core is different ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service @@ -108,4 +102,8 @@ do_install_virtclass-native() { # dbus-glib-native and dbus-glib need this xml file ./bus/dbus-daemon --introspect > ${STAGING_DATADIR_NATIVE}/dbus/dbus-bus-introspect.xml } + +do_install_virtclass-nativesdk() { + autotools_do_install +} BBCLASSEXTEND = "native nativesdk" diff --git a/meta/recipes-core/dbus/dbus_1.4.12.bb b/meta/recipes-core/dbus/dbus_1.4.12.bb index ada53c9a21..9324af7f0a 100644 --- a/meta/recipes-core/dbus/dbus_1.4.12.bb +++ b/meta/recipes-core/dbus/dbus_1.4.12.bb @@ -1,4 +1,7 @@ include dbus.inc + +PR = "r1" + SRC_URI[md5sum] = "104f2ea94c10a896dfb1edecb5714cb1" SRC_URI[sha256sum] = "da3c97fd546610558d588799e27c4fa81101e754acbcd34747a42c131f30dbe7" diff --git a/meta/recipes-core/eglibc/eglibc-2.12/ppc-enable-603e-cpu.patch b/meta/recipes-core/eglibc/eglibc-2.12/ppc-enable-603e-cpu.patch new file mode 100644 index 0000000000..5c90e5bae0 --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.12/ppc-enable-603e-cpu.patch @@ -0,0 +1,26 @@ +We now pass --with-cpu option to eglibc this ends up with configure errors if we do +not pass a cpu which eglibc has support for in sysdeps + +| checking sysdep dirs... configure: error: The 603e subspecies of powerpc is not supported. +| + bbfatal 'oe_runconf failed' +| + echo 'ERROR: oe_runconf failed' + +We fix this by adding the 603e sub directories with Implies to generic +powerpc to overcome this error + +Upstream-Status: Inappropriate [OE config related] + +Signed-off-by: Khem Raj <raj.khem@gmail.com> + +Index: libc/ports/sysdeps/powerpc/powerpc32/603e/Implies +=================================================================== +--- /dev/null 1970-01-01 00:00:00.000000000 +0000 ++++ libc/ports/sysdeps/powerpc/powerpc32/603e/Implies 2011-09-17 19:18:57.593292084 -0700 +@@ -0,0 +1 @@ ++powerpc/powerpc32 +Index: libc/ports/sysdeps/unix/sysv/linux/powerpc/powerpc32/603e/Implies +=================================================================== +--- /dev/null 1970-01-01 00:00:00.000000000 +0000 ++++ libc/ports/sysdeps/unix/sysv/linux/powerpc/powerpc32/603e/Implies 2011-09-17 19:17:48.613292100 -0700 +@@ -0,0 +1 @@ ++powerpc/powerpc32 diff --git a/meta/recipes-core/eglibc/eglibc-initial.inc b/meta/recipes-core/eglibc/eglibc-initial.inc index 448f73a971..906251633b 100644 --- a/meta/recipes-core/eglibc/eglibc-initial.inc +++ b/meta/recipes-core/eglibc/eglibc-initial.inc @@ -60,4 +60,16 @@ do_siteconfig () { : } +SSTATEPOSTINSTFUNCS += "eglibcinitial_sstate_postinst" +eglibcinitial_sstate_postinst() { + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] + then + # Recreate the symlinks to ensure they point to the correct location + for t in linux asm asm-generic; do + rm -f ${STAGING_DIR_TCBOOTSTRAP}${includedir}/$t + ln -s ${STAGING_DIR_TARGET}${includedir}/$t ${STAGING_DIR_TCBOOTSTRAP}${includedir}/ + done + fi +} + do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_TCBOOTSTRAP}" diff --git a/meta/recipes-core/eglibc/eglibc.inc b/meta/recipes-core/eglibc/eglibc.inc index fe9f8bab55..272fcb6273 100644 --- a/meta/recipes-core/eglibc/eglibc.inc +++ b/meta/recipes-core/eglibc/eglibc.inc @@ -40,6 +40,7 @@ ARM_INSTRUCTION_SET = "arm" # eglibc uses PARALLELMFLAGS variable to pass parallel build info so transfer # PARALLEL_MAKE into PARALLELMFLAGS and empty out PARALLEL_MAKE EGLIBCPARALLELISM := "PARALLELMFLAGS="${PARALLEL_MAKE}"" +EXTRA_OEMAKE[vardepsexclude] += "EGLIBCPARALLELISM" EXTRA_OEMAKE += ${EGLIBCPARALLELISM} PARALLEL_MAKE = "" diff --git a/meta/recipes-core/eglibc/eglibc_2.12.bb b/meta/recipes-core/eglibc/eglibc_2.12.bb index a9d208b756..42202196da 100644 --- a/meta/recipes-core/eglibc/eglibc_2.12.bb +++ b/meta/recipes-core/eglibc/eglibc_2.12.bb @@ -1,7 +1,7 @@ require eglibc.inc DEPENDS += "gperf-native" -PR = "r24" +PR = "r27" SRCREV = "14158" @@ -12,6 +12,7 @@ SRC_URI = "svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};proto=http file://shorten-build-commands.patch \ file://mips-rld-map-check.patch \ file://armv4-eabi-compile-fix.patch \ + file://ppc-enable-603e-cpu.patch \ file://etc/ld.so.conf \ file://generate-supported.mk \ " diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb b/meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb index fed72a13db..611127dddd 100644 --- a/meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb +++ b/meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb @@ -1,6 +1,6 @@ require glib.inc -PR = "r7" +PR = "r8" SRC_URI = "${GNOME_MIRROR}/glib/2.27/glib-${PV}.tar.bz2 \ file://configure-libtool.patch \ diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb b/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb index 24c599234e..7430d88742 100644 --- a/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb +++ b/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb @@ -1,6 +1,6 @@ require glib.inc -PR = "r4" +PR = "r5" PE = "1" SRC_URI = "${GNOME_MIRROR}/glib/2.28/glib-${PV}.tar.bz2 \ diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index d2415fdd30..5025085690 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -19,7 +19,7 @@ DEPENDS_virtclass-nativesdk = "libtool-nativesdk" PACKAGES =+ "${PN}-utils " LEAD_SONAME = "libglib-2.0.*" -FILES_${PN}-utils = "${bindir}/*" +FILES_${PN}-utils = "${bindir}/* ${datadir}/glib-2.0/gettext" inherit autotools pkgconfig gettext diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc index be7d387c9c..df9252a03b 100644 --- a/meta/recipes-core/ncurses/ncurses.inc +++ b/meta/recipes-core/ncurses/ncurses.inc @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = "file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc SECTION = "libs" DEPENDS = "ncurses-native" DEPENDS_virtclass-native = "" -INC_PR = "r1" +INC_PR = "r2" inherit autotools binconfig multilib_header @@ -26,6 +26,36 @@ ENABLE_WIDEC = "true" # builds. BUILD_CPPFLAGS += "-D_GNU_SOURCE" +# Helper function for do_configure to allow multiple configurations +# $1 the directory to run configure in +# $@ the arguments to pass to configure +ncurses_configure() { + mkdir -p $1 + cd $1 + shift + oe_runconf \ + --disable-static \ + --without-debug \ + --without-ada \ + --without-gpm \ + --enable-hard-tabs \ + --enable-xmc-glitch \ + --enable-colorfgbg \ + --with-termpath='${sysconfdir}/termcap:${datadir}/misc/termcap' \ + --with-terminfo-dirs='${sysconfdir}/terminfo:${datadir}/terminfo' \ + --with-shared \ + --disable-big-core \ + --program-prefix= \ + --with-ticlib \ + --with-termlib=tinfo \ + --enable-sigwinch \ + --enable-pc-files \ + --disable-rpath-hack \ + --with-manpage-format=normal \ + "$@" || return 1 + cd .. +} + # Override the function from the autotools class; ncurses requires a # patched autoconf213 to generate the configure script. This autoconf # is not available so that the shipped script will be used. @@ -35,36 +65,10 @@ do_configure() { # not the case for /dev/null redirections) export cf_cv_working_poll=yes - for i in \ - 'narrowc' \ - 'widec --enable-widec --without-progs'; do - set -- $i - mkdir -p $1 - cd $1 - shift - - oe_runconf \ - --disable-static \ - --without-debug \ - --without-ada \ - --without-gpm \ - --enable-hard-tabs \ - --enable-xmc-glitch \ - --enable-colorfgbg \ - --with-termpath='${sysconfdir}/termcap:${datadir}/misc/termcap' \ - --with-terminfo-dirs='${sysconfdir}/terminfo:${datadir}/terminfo' \ - --with-shared \ - --disable-big-core \ - --program-prefix= \ - --with-ticlib \ - --with-termlib=tinfo \ - --enable-sigwinch \ - --enable-pc-files \ - --disable-rpath-hack \ - --with-manpage-format=normal \ - "$@" - cd .. - done + ncurses_configure "narrowc" || \ + return 1 + ! ${ENABLE_WIDEC} || \ + ncurses_configure "widec" "--enable-widec" "--without-progs" } do_compile() { diff --git a/meta/recipes-core/tasks/task-sdk-host-nativesdk.bb b/meta/recipes-core/tasks/task-sdk-host-nativesdk.bb index 5ec40b140c..920f359eea 100644 --- a/meta/recipes-core/tasks/task-sdk-host-nativesdk.bb +++ b/meta/recipes-core/tasks/task-sdk-host-nativesdk.bb @@ -3,7 +3,7 @@ # DESCRIPTION = "Host packages for the standalone SDK or external toolchain" -PR = "r10" +PR = "r11" LICENSE = "MIT" ALLOW_EMPTY = "1" @@ -22,6 +22,8 @@ RDEPENDS_${PN} = "\ unfs-server-nativesdk \ opkg-nativesdk \ libtool-nativesdk \ + autoconf-nativesdk \ + automake-nativesdk \ " RDEPENDS_${PN}_darwin8 = "\ diff --git a/meta/recipes-core/udev/files/mount.blacklist b/meta/recipes-core/udev/files/mount.blacklist index d3ebb17176..7c7d938002 100644 --- a/meta/recipes-core/udev/files/mount.blacklist +++ b/meta/recipes-core/udev/files/mount.blacklist @@ -1,3 +1,4 @@ /dev/loop /dev/ram /dev/mtdblock +/dev/md diff --git a/meta/recipes-core/udev/files/udev-166-v4l1-1.patch b/meta/recipes-core/udev/files/udev-166-v4l1-1.patch new file mode 100644 index 0000000000..2086fe1e27 --- /dev/null +++ b/meta/recipes-core/udev/files/udev-166-v4l1-1.patch @@ -0,0 +1,50 @@ +Upstream-Status: Backport + +Submitted By: Matt Burgess <matthew_at_linuxfromscratch_dot_org> +Date: 2011-03-26 +Initial Package Version: 166 +Upstream Status: From upstream +Origin: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=4ace8a43ac2cbbd4d6f5c29fc461c3caa8f8545b +Description: Fixes a compilation error caused by the removal of the + Video for Linux 1 API from Linux kernels from 2.6.38 + onwards. + +diff -Naur udev-166.orig/extras/v4l_id/v4l_id.c udev-166/extras/v4l_id/v4l_id.c +--- udev-166.orig/extras/v4l_id/v4l_id.c 2009-12-03 12:45:03.000000000 +0000 ++++ udev-166/extras/v4l_id/v4l_id.c 2011-03-25 20:26:33.000000000 +0000 +@@ -28,7 +28,6 @@ + #include <sys/types.h> + #include <sys/time.h> + #include <sys/ioctl.h> +-#include <linux/videodev.h> + #include <linux/videodev2.h> + + int main (int argc, char *argv[]) +@@ -39,7 +38,6 @@ + }; + int fd; + char *device; +- struct video_capability v1cap; + struct v4l2_capability v2cap; + + while (1) { +@@ -82,19 +80,6 @@ + if ((v2cap.capabilities & V4L2_CAP_RADIO) > 0) + printf("radio:"); + printf("\n"); +- } else if (ioctl (fd, VIDIOCGCAP, &v1cap) == 0) { +- printf("ID_V4L_VERSION=1\n"); +- printf("ID_V4L_PRODUCT=%s\n", v1cap.name); +- printf("ID_V4L_CAPABILITIES=:"); +- if ((v1cap.type & VID_TYPE_CAPTURE) > 0) +- printf("capture:"); +- if ((v1cap.type & VID_TYPE_OVERLAY) > 0) +- printf("video_overlay:"); +- if (v1cap.audios > 0) +- printf("audio:"); +- if ((v1cap.type & VID_TYPE_TUNER) > 0) +- printf("tuner:"); +- printf("\n"); + } + + close (fd); diff --git a/meta/recipes-core/udev/udev-164/init b/meta/recipes-core/udev/udev-164/init index 9ce95ee4c2..073942f27e 100644 --- a/meta/recipes-core/udev/udev-164/init +++ b/meta/recipes-core/udev/udev-164/init @@ -48,10 +48,10 @@ kill_udevd > "/dev/null" 2>&1 /sbin/udevadm control --env=STARTUP=1 if [ "$not_first_boot" != "" ];then - /sbin/udevadm trigger --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform + /sbin/udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform (/sbin/udevadm settle --timeout=3; /sbin/udevadm control --env=STARTUP=)& else - /sbin/udevadm trigger + /sbin/udevadm trigger --action=add /sbin/udevadm settle fi diff --git a/meta/recipes-core/udev/udev-extraconf_0.0.bb b/meta/recipes-core/udev/udev-extraconf_0.0.bb index e17d94435e..d0d0e84276 100644 --- a/meta/recipes-core/udev/udev-extraconf_0.0.bb +++ b/meta/recipes-core/udev/udev-extraconf_0.0.bb @@ -3,7 +3,7 @@ DESCRIPTION = "Extra machine specific configuration files for udev, specifically LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://${WORKDIR}/COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe" -PR = "r1" +PR = "r2" SRC_URI = "file://mount.blacklist \ file://COPYING.GPL" diff --git a/meta/recipes-core/udev/udev-new.inc b/meta/recipes-core/udev/udev-new.inc index 4c4451f14b..0247a83aff 100644 --- a/meta/recipes-core/udev/udev-new.inc +++ b/meta/recipes-core/udev/udev-new.inc @@ -51,8 +51,8 @@ FILES_libudev = "${base_libdir}/libudev.so.*" FILES_libudev-dbg = "${base_libdir}/.debug/libudev.so.*" FILES_libudev-dev = "${includedir}/libudev.h ${libdir}/libudev.so ${libdir}/libudev.la \ ${libdir}/libudev.a ${libdir}/pkgconfig/libudev.pc" -FILES_libgudev = "${libdir}/libgudev*.so.*" -FILES_libgudev-dbg = "${libdir}/.debug/libgudev*.so.*" +FILES_libgudev = "${base_libdir}/libgudev*.so.* ${libdir}/libgudev*.so.*" +FILES_libgudev-dbg = "${base_libdir}/.debug/libgudev*.so.* ${libdir}/.debug/libgudev*.so.*" FILES_libgudev-dev = "${includedir}/gudev* ${libdir}/libgudev*.so ${libdir}/libgudev*.la \ ${libdir}/libgudev*.a ${libdir}/pkgconfig/gudev*.pc" FILES_udev-cache = "${sysconfdir}/init.d/udev-cache" diff --git a/meta/recipes-core/udev/udev_164.bb b/meta/recipes-core/udev/udev_164.bb index 567e62e3ff..7cbe4d8b60 100644 --- a/meta/recipes-core/udev/udev_164.bb +++ b/meta/recipes-core/udev/udev_164.bb @@ -1,6 +1,8 @@ include udev-new.inc -PR = "r3" +PR = "r6" + +SRC_URI += "file://udev-166-v4l1-1.patch" SRC_URI[md5sum] = "fddac2d54761ea34865af9467377ca9f" SRC_URI[sha256sum] = "c12e66280b5e1465f6587a8cfa47d7405c4caa7e52ce5dd13478d04f6ec05e5c" diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc index 1f242b7fa7..dcf0ed9431 100644 --- a/meta/recipes-core/util-linux/util-linux.inc +++ b/meta/recipes-core/util-linux/util-linux.inc @@ -29,7 +29,8 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk util-linux-sfd util-linux-swaponoff util-linux-losetup util-linux-umount \ util-linux-mount util-linux-readprofile util-linux-libblkid \ util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev \ - util-linux-uuidgen util-linux-lscpu" + util-linux-uuidgen util-linux-lscpu util-linux-fsck util-linux-blkid \ + util-linux-chkdupexe util-linux-mkfs util-linux-mcookie" EXTRA_OECONF = "--disable-use-tty-group --disable-makeinstall-chown --enable-elvtune --enable-init --enable-kill --enable-last \ --enable-mesg --enable-partx --enable-raw --enable-rdev --enable-reset \ @@ -44,6 +45,7 @@ FILES_util-linux-sfdisk = "${sbindir}/sfdisk" FILES_util-linux-swaponoff = "${base_sbindir}/swapon.${PN} ${sbindir}/swapoff.${PN}" FILES_util-linux-losetup = "${base_sbindir}/losetup.${PN}" FILES_util-linux-mount = "${base_bindir}/mount.${PN}" +FILES_util-linux-mcookie = "${bindir}/mcookie" FILES_util-linux-umount = "${base_bindir}/umount.${PN}" FILES_util-linux-readprofile = "${base_sbindir}/readprofile.${PN}" FILES_util-linux-uuidgen = "${bindir}/uuidgen" @@ -54,8 +56,18 @@ FILES_util-linux-libuuid = "${libdir}/libuuid.so.*" FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${libdir}/libuuid.a ${libdir}/libuuid.la ${includedir}/uuid" FILES_util-linux-lscpu = "${bindir}/lscpu" -RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile " +FILES_util-linux-fsck = "${base_sbindir}/fsck*" +FILES_util-linux-chkdupexe = "${bindir}/chkdupexe" +FILES_util-linux-mkfs = "${sbindir}/mkfs" + +# Util-linux' blkid replaces the e2fsprogs one +FILES_util-linux-blkid = "${base_sbindir}/blkid*" +RCONFLICTS_util-linux-blkid = "e2fsprogs-blkid" +RREPLACES_util-linux-blkid = "e2fsprogs-blkid" + RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup" +RDEPENDS_${PN}-chkdupexe = "perl" +RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile util-linux-mkfs " RRECOMMENDS_${PN}_virtclass-native = "" RDEPENDS_${PN}_virtclass-native = "" @@ -172,7 +184,6 @@ pkg_postinst_${PN} () { update-alternatives --install ${base_sbindir}/pivot_root pivot_root pivot_root.${PN} 100 # update-alternatives --install ${base_sbindir}/sln sln sln.${PN} 100 update-alternatives --install ${base_sbindir}/mkfs.minix mkfs.minix mkfs.minix.${PN} 100 - update-alternatives --install ${base_sbindir}/fsck.minix fsck.minix fsck.minix.${PN} 100 update-alternatives --install ${bindir}/hexdump hexdump hexdump.${PN} 100 update-alternatives --install ${bindir}/last last last.${PN} 100 update-alternatives --install ${bindir}/logger logger logger.${PN} 100 @@ -201,7 +212,6 @@ pkg_prerm_${PN} () { update-alternatives --remove shutdown shutdown.${PN} # update-alternatives --remove sln sln.${PN} update-alternatives --remove mkfs.minix mkfs.minix.${PN} - update-alternatives --remove fsck.minix fsck.minix.${PN} update-alternatives --remove hexdump hexdump.${PN} update-alternatives --remove last last.${PN} update-alternatives --remove logger logger.${PN} @@ -252,4 +262,22 @@ pkg_prerm_util-linux-swaponoff () { update-alternatives --remove swapon swapon.${PN} } +pkg_postinst_util-linux-fsck () { + update-alternatives --install ${base_sbindir}/fsck.minix fsck.minix fsck.minix.${PN} 100 + update-alternatives --install ${base_sbindir}/fsck fsck fsck.${PN} 100 +} + +pkg_prerm_util-linux-fsck () { + update-alternatives --remove fsck.minix fsck.minix.${PN} + update-alternatives --remove fsck fsck.${PN} +} + +pkg_postinst_util-linux-blkid () { + update-alternatives --install ${base_sbindir}/blkid blkid blkid.${PN} 100 +} + +pkg_prerm_util-linux-blkid () { + update-alternatives --remove blkid blkid.${PN} +} + BBCLASSEXTEND = "native" diff --git a/meta/recipes-core/util-linux/util-linux_2.19.1.bb b/meta/recipes-core/util-linux/util-linux_2.19.1.bb index d6d6f9b97d..e2fb727280 100644 --- a/meta/recipes-core/util-linux/util-linux_2.19.1.bb +++ b/meta/recipes-core/util-linux/util-linux_2.19.1.bb @@ -1,5 +1,5 @@ MAJOR_VERSION = "2.19" -PR = "r4" +PR = "r10" require util-linux.inc # note that `lscpu' is under GPLv3+ @@ -44,3 +44,7 @@ addtask remove_lscpu before do_configure after do_patch # we need to disable it for older versions EXTRA_OECONF += "ac_cv_func_fallocate=no" EXTRA_OECONF_virtclass-native += "--disable-fallocate --disable-use-tty-group" + +do_install_append () { + sed -i -e '1s,.*,#!${bindir}/env perl,' ${D}${bindir}/chkdupexe +} diff --git a/meta/recipes-core/zlib/files/Makefile.am b/meta/recipes-core/zlib/files/Makefile.am index b66d299d8f..db072dfe4a 100644 --- a/meta/recipes-core/zlib/files/Makefile.am +++ b/meta/recipes-core/zlib/files/Makefile.am @@ -7,3 +7,6 @@ libz_la_SOURCES = adler32.c compress.c crc32.c gzlib.c gzclose.c gzread.c \ libz_la_LDFLAGS = -version-number 1:2:5 --version-script zlib.map include_HEADERS = zconf.h zlib.h zlibdefs.h + +pkgconfigdir = $(libdir)/pkgconfig +pkgconfig_DATA = zlib.pc diff --git a/meta/recipes-core/zlib/files/configure.ac b/meta/recipes-core/zlib/files/configure.ac index 4761b7ef28..5792b15103 100644 --- a/meta/recipes-core/zlib/files/configure.ac +++ b/meta/recipes-core/zlib/files/configure.ac @@ -43,6 +43,11 @@ cat > zlibdefs.h << EOF #endif EOF -AC_CONFIG_FILES([Makefile]) +AC_SUBST(sharedlibdir,$libdir) + +AC_CONFIG_FILES([ +Makefile +zlib.pc +]) AC_OUTPUT diff --git a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch b/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch new file mode 100644 index 0000000000..038c1a2748 --- /dev/null +++ b/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch @@ -0,0 +1,20 @@ +Upstream-Status: Pending + +see +https://bugs.gentoo.org/316377?id=316377 +https://bugs.freedesktop.org/show_bug.cgi?id=33710 +http://lists.freedesktop.org/archives/poppler-bugs/2011-January/006014.html +for details + +diff -up zlib-1.2.5/zlib.h.pom zlib-1.2.5/zlib.h +--- zlib-1.2.5/zlib.h.pom 2010-04-20 06:12:48.000000000 +0200 ++++ zlib-1.2.5/zlib.h 2010-06-16 13:08:59.000000000 +0200 +@@ -1578,7 +1578,7 @@ ZEXTERN int ZEXPORT inflateBackInit_ OF( + # define gzoffset gzoffset64 + # define adler32_combine adler32_combine64 + # define crc32_combine crc32_combine64 +-# ifdef _LARGEFILE64_SOURCE ++# ifndef _LARGEFILE64_SOURCE + ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); + ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int)); + ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile)); diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb b/meta/recipes-core/zlib/zlib_1.2.5.bb index 96dab25f9b..14b3987078 100644 --- a/meta/recipes-core/zlib/zlib_1.2.5.bb +++ b/meta/recipes-core/zlib/zlib_1.2.5.bb @@ -7,11 +7,12 @@ LICENSE = "Zlib" LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d" DEPENDS = "libtool-cross" -PR = "r0" +PR = "r2" SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \ file://configure.ac \ - file://Makefile.am" + file://Makefile.am \ + file://fix.inverted.LFS.logic.patch" SRC_URI[md5sum] = "be1e89810e66150f5b0327984d8625a0" SRC_URI[sha256sum] = "239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307" diff --git a/meta/recipes-devtools/apt/apt-0.7.14/localefixes.patch b/meta/recipes-devtools/apt/apt-0.7.14/localefixes.patch new file mode 100644 index 0000000000..80252732e2 --- /dev/null +++ b/meta/recipes-devtools/apt/apt-0.7.14/localefixes.patch @@ -0,0 +1,91 @@ +Add in missing header includes to resolve compile failures with recent +compiler/glibc combinations. + +Upstream-Status: Inappropriate [Resolved upstream] + +RP 2011/11/23 + +Index: apt-0.7.14/apt-pkg/init.cc +=================================================================== +--- apt-0.7.14.orig/apt-pkg/init.cc 2011-11-23 22:48:53.544637868 +0000 ++++ apt-0.7.14/apt-pkg/init.cc 2011-11-23 22:48:59.456638260 +0000 +@@ -16,6 +16,7 @@ + #include <config.h> + #include <cstdlib> + #include <sys/stat.h> ++#include <locale> + /*}}}*/ + + #define Stringfy_(x) # x +Index: apt-0.7.14/cmdline/apt-cache.cc +=================================================================== +--- apt-0.7.14.orig/cmdline/apt-cache.cc 2011-11-23 22:53:29.048631067 +0000 ++++ apt-0.7.14/cmdline/apt-cache.cc 2011-11-23 22:54:15.784616212 +0000 +@@ -32,6 +32,7 @@ + #include <apti18n.h> + + #include <locale.h> ++#include <locale> + #include <iostream> + #include <unistd.h> + #include <errno.h> +Index: apt-0.7.14/cmdline/apt-cdrom.cc +=================================================================== +--- apt-0.7.14.orig/cmdline/apt-cdrom.cc 2011-11-23 22:53:29.064631096 +0000 ++++ apt-0.7.14/cmdline/apt-cdrom.cc 2011-11-23 22:53:57.616630261 +0000 +@@ -27,6 +27,7 @@ + //#include "indexcopy.h" + + #include <locale.h> ++#include <locale> + #include <iostream> + #include <fstream> + #include <vector> +Index: apt-0.7.14/cmdline/apt-config.cc +=================================================================== +--- apt-0.7.14.orig/cmdline/apt-config.cc 2011-11-23 22:50:16.796635352 +0000 ++++ apt-0.7.14/cmdline/apt-config.cc 2011-11-23 22:50:25.640633906 +0000 +@@ -27,6 +27,7 @@ + #include <locale.h> + #include <iostream> + #include <string> ++#include <locale> + /*}}}*/ + using namespace std; + +Index: apt-0.7.14/cmdline/apt-extracttemplates.cc +=================================================================== +--- apt-0.7.14.orig/cmdline/apt-extracttemplates.cc 2011-11-23 22:53:29.080631084 +0000 ++++ apt-0.7.14/cmdline/apt-extracttemplates.cc 2011-11-23 22:53:38.304630439 +0000 +@@ -39,6 +39,7 @@ + #include <config.h> + #include <apti18n.h> + #include "apt-extracttemplates.h" ++#include <locale> + /*}}}*/ + + using namespace std; +Index: apt-0.7.14/cmdline/apt-get.cc +=================================================================== +--- apt-0.7.14.orig/cmdline/apt-get.cc 2011-11-23 22:53:29.096631090 +0000 ++++ apt-0.7.14/cmdline/apt-get.cc 2011-11-23 22:53:49.368629452 +0000 +@@ -48,6 +48,7 @@ + + #include <set> + #include <locale.h> ++#include <locale> + #include <langinfo.h> + #include <fstream> + #include <termios.h> +Index: apt-0.7.14/cmdline/apt-sortpkgs.cc +=================================================================== +--- apt-0.7.14.orig/cmdline/apt-sortpkgs.cc 2011-11-23 22:52:03.872640247 +0000 ++++ apt-0.7.14/cmdline/apt-sortpkgs.cc 2011-11-23 22:52:10.880638611 +0000 +@@ -27,6 +27,7 @@ + + #include <locale.h> + #include <unistd.h> ++#include <locale> + /*}}}*/ + + using namespace std; diff --git a/meta/recipes-devtools/apt/apt-0.7.14/makerace.patch b/meta/recipes-devtools/apt/apt-0.7.14/makerace.patch new file mode 100644 index 0000000000..403711f013 --- /dev/null +++ b/meta/recipes-devtools/apt/apt-0.7.14/makerace.patch @@ -0,0 +1,23 @@ +I was seeing various issues with parallel make, mainly due to to what was likely +partially installed headers. If you change into the source directory and +"NOISY=1 make ../obj/apt-pkg/sourcelist.opic" in apt-pkg, you'll see it +doesn't have any dependencies on the headers being installed. This patch +fixes that so things build correctly. + +RP 2012/3/19 + +Upstream-Status: Pending + +Index: apt-0.7.14/buildlib/library.mak +=================================================================== +--- apt-0.7.14.orig/buildlib/library.mak ++++ apt-0.7.14/buildlib/library.mak +@@ -61,7 +61,7 @@ $(LIB)/lib$(LIBRARY)$(LIBEXT).so.$(MAJOR + + # Compilation rules + vpath %.cc $(SUBDIRS) +-$(OBJ)/%.opic: %.cc ++$(OBJ)/%.opic: %.cc $($(LOCAL)-HEADERS) + echo Compiling $< to $@ + $(CXX) -c $(INLINEDEPFLAG) $(CPPFLAGS) $(CXXFLAGS) $(PICFLAGS) -o $@ $< + $(DoDep) diff --git a/meta/recipes-devtools/apt/apt-0.7.14/remove-redeclaration.patch b/meta/recipes-devtools/apt/apt-0.7.14/remove-redeclaration.patch new file mode 100644 index 0000000000..8d7c891545 --- /dev/null +++ b/meta/recipes-devtools/apt/apt-0.7.14/remove-redeclaration.patch @@ -0,0 +1,63 @@ +Fix build errors on gcc 4.7: + +deb/deblistparser.cc: In member function 'virtual short unsigned int debListParser::VersionHash()': +deb/deblistparser.cc:212:13: error: redeclaration of 'char* I' +deb/deblistparser.cc:202:22: error: 'const char** I' previously declared here + +Upstream-Status: Backport +Signed-off-by: Robert Yang <liezhi.yang@windriver.com> +--- + apt-pkg/deb/deblistparser.cc | 10 +++++----- + cmdline/apt-get.cc | 8 ++++---- + 2 files changed, 9 insertions(+), 9 deletions(-) + +diff --git a/apt-pkg/deb/deblistparser.cc b/apt-pkg/deb/deblistparser.cc +--- a/apt-pkg/deb/deblistparser.cc ++++ b/apt-pkg/deb/deblistparser.cc +@@ -209,18 +209,18 @@ unsigned short debListParser::VersionHash() + /* Strip out any spaces from the text, this undoes dpkgs reformatting + of certain fields. dpkg also has the rather interesting notion of + reformatting depends operators < -> <= */ +- char *I = S; ++ char *J = S; + for (; Start != End; Start++) + { + if (isspace(*Start) == 0) +- *I++ = tolower(*Start); ++ *J++ = tolower(*Start); + if (*Start == '<' && Start[1] != '<' && Start[1] != '=') +- *I++ = '='; ++ *J++ = '='; + if (*Start == '>' && Start[1] != '>' && Start[1] != '=') +- *I++ = '='; ++ *J++ = '='; + } + +- Result = AddCRC16(Result,S,I - S); ++ Result = AddCRC16(Result,S,J - S); + } + + return Result; +diff --git a/cmdline/apt-get.cc b/cmdline/apt-get.cc +--- a/cmdline/apt-get.cc ++++ b/cmdline/apt-get.cc +@@ -1752,12 +1752,12 @@ bool DoInstall(CommandLine &CmdL) + if ((*Cache)[I].Install() == false) + continue; + +- const char **J; +- for (J = CmdL.FileList + 1; *J != 0; J++) +- if (strcmp(*J,I.Name()) == 0) ++ const char **K; ++ for (K = CmdL.FileList + 1; *K != 0; K++) ++ if (strcmp(*K,I.Name()) == 0) + break; + +- if (*J == 0) { ++ if (*K == 0) { + List += string(I.Name()) + " "; + VersionsList += string(Cache[I].CandVersion) + "\n"; + } +-- +1.7.1 + diff --git a/meta/recipes-devtools/apt/apt-native.inc b/meta/recipes-devtools/apt/apt-native.inc index b16f99e93c..ddaeaf9251 100644 --- a/meta/recipes-devtools/apt/apt-native.inc +++ b/meta/recipes-devtools/apt/apt-native.inc @@ -40,10 +40,11 @@ do_install_base () { install -m 0755 bin/apt-extracttemplates ${D}${bindir}/ eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'` - oe_libinstall -so -C bin libapt-pkg$GLIBC_VER-6 ${D}${libdir}/ - ln -sf libapt-pkg$GLIBC_VER-6.so ${D}${libdir}/libapt-pkg.so - oe_libinstall -so -C bin libapt-inst$GLIBC_VER-6 ${D}${libdir}/ - ln -sf libapt-inst$GLIBC_VER-6.so ${D}${libdir}/libapt-inst.so + eval `cat environment.mak | grep ^LIBSTDCPP_VER | sed -e's, = ,=,'` + oe_libinstall -so -C bin libapt-pkg$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/ + ln -sf libapt-pkg$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-pkg.so + oe_libinstall -so -C bin libapt-inst$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/ + ln -sf libapt-inst$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-inst.so install -d ${D}${libdir}/apt/methods install -m 0755 bin/methods/* ${D}${libdir}/apt/methods/ diff --git a/meta/recipes-devtools/apt/apt-native_0.7.14.bb b/meta/recipes-devtools/apt/apt-native_0.7.14.bb index c82d606ebe..ca5476b6b2 100644 --- a/meta/recipes-devtools/apt/apt-native_0.7.14.bb +++ b/meta/recipes-devtools/apt/apt-native_0.7.14.bb @@ -1,6 +1,6 @@ require apt-native.inc -PR = "r5" +PR = "r8" SRC_URI += "file://nodoc.patch \ file://noconfigure.patch \ diff --git a/meta/recipes-devtools/apt/apt-package.inc b/meta/recipes-devtools/apt/apt-package.inc index 2e3be3885b..1909e3b197 100644 --- a/meta/recipes-devtools/apt/apt-package.inc +++ b/meta/recipes-devtools/apt/apt-package.inc @@ -78,10 +78,11 @@ do_install () { install -m 0755 bin/apt-extracttemplates ${D}${bindir}/ eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'` - oe_libinstall -so -C bin libapt-pkg$GLIBC_VER-6 ${D}${libdir}/ - ln -sf libapt-pkg$GLIBC_VER-6.so ${D}${libdir}/libapt-pkg.so - oe_libinstall -so -C bin libapt-inst$GLIBC_VER-6 ${D}${libdir}/ - ln -sf libapt-inst$GLIBC_VER-6.so ${D}${libdir}/libapt-inst.so + eval `cat environment.mak | grep ^LIBSTDCPP_VER | sed -e's, = ,=,'` + oe_libinstall -so -C bin libapt-pkg$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/ + ln -sf libapt-pkg$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-pkg.so + oe_libinstall -so -C bin libapt-inst$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/ + ln -sf libapt-inst$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-inst.so install -d ${D}${libdir}/apt/methods install -m 0755 bin/methods/* ${D}${libdir}/apt/methods/ diff --git a/meta/recipes-devtools/apt/apt.inc b/meta/recipes-devtools/apt/apt.inc index 546683f9bc..0d241a9ab9 100644 --- a/meta/recipes-devtools/apt/apt.inc +++ b/meta/recipes-devtools/apt/apt.inc @@ -5,6 +5,9 @@ SECTION = "base" SRC_URI = "${DEBIAN_MIRROR}/main/a/apt/apt_${PV}.tar.gz \ file://no-ko-translation.patch \ file://use-host.patch \ + file://localefixes.patch \ + file://makerace.patch \ + file://remove-redeclaration.patch \ " inherit autotools gettext diff --git a/meta/recipes-devtools/apt/apt_0.7.14.bb b/meta/recipes-devtools/apt/apt_0.7.14.bb index 93eebe9502..9ace6d25df 100644 --- a/meta/recipes-devtools/apt/apt_0.7.14.bb +++ b/meta/recipes-devtools/apt/apt_0.7.14.bb @@ -3,7 +3,7 @@ RDEPENDS_${PN} = "dpkg" LIC_FILES_CHKSUM = "file://COPYING.GPL;md5=0636e73ff0215e8d672dc4c32c317bb3" require apt.inc -PR = "r8" +PR = "r11" SRC_URI += "file://nodoc.patch \ file://includes-fix.patch " diff --git a/meta/recipes-devtools/autoconf/autoconf.inc b/meta/recipes-devtools/autoconf/autoconf.inc index 08a1b02219..071e58cebf 100644 --- a/meta/recipes-devtools/autoconf/autoconf.inc +++ b/meta/recipes-devtools/autoconf/autoconf.inc @@ -7,6 +7,8 @@ HOMEPAGE = "http://www.gnu.org/software/autoconf/" SECTION = "devel" DEPENDS += "m4-native" RDEPENDS_${PN} = "m4 gnu-config" +RDEPENDS_${PN}_virtclass-native = "m4-native gnu-config-native" +RDEPENDS_${PN}_virtclass-nativesdk = "m4-nativesdk gnu-config-nativesdk" SRC_URI = "${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.bz2 \ file://program_prefix.patch" diff --git a/meta/recipes-devtools/autoconf/autoconf_2.68.bb b/meta/recipes-devtools/autoconf/autoconf_2.68.bb index c6209a37eb..0ca991cf5d 100644 --- a/meta/recipes-devtools/autoconf/autoconf_2.68.bb +++ b/meta/recipes-devtools/autoconf/autoconf_2.68.bb @@ -1,6 +1,6 @@ require autoconf.inc -PR = "r2" +PR = "r4" PARALLEL_MAKE = "" @@ -14,7 +14,7 @@ SRC_URI += "file://autoreconf-include.patch \ file://autoreconf-foreign.patch \ file://autoreconf-gnuconfigize.patch \ file://autoheader-nonfatal-warnings.patch \ - ${@['file://path_prog_fixes.patch', ''][bb.data.inherits_class('native', d)]} \ + ${@['file://path_prog_fixes.patch', ''][bb.data.inherits_class('native', d) or bb.data.inherits_class('nativesdk', d)]} \ file://config_site.patch \ file://remove-usr-local-lib-from-m4.patch \ " @@ -25,6 +25,12 @@ SRC_URI[sha256sum] = "c491fb273fd6d4ca925e26ceed3d177920233c76d542b150ff35e57145 DEPENDS_virtclass-native = "m4-native gnu-config-native" RDEPENDS_${PN}_virtclass-native = "m4-native gnu-config-native" +DEPENDS_virtclass-nativesdk = "m4-nativesdk gnu-config-nativesdk" +RDEPENDS_${PN}_virtclass-nativesdk = "m4-nativesdk gnu-config-nativesdk" + SRC_URI_append_virtclass-native = " file://fix_path_xtra.patch" -BBCLASSEXTEND = "native" +EXTRA_OECONF += "ac_cv_path_M4=m4" + +BBCLASSEXTEND = "native nativesdk" + diff --git a/meta/recipes-devtools/automake/automake.inc b/meta/recipes-devtools/automake/automake.inc index f217e1432b..cf3cc886e6 100644 --- a/meta/recipes-devtools/automake/automake.inc +++ b/meta/recipes-devtools/automake/automake.inc @@ -4,7 +4,7 @@ Standards. Automake requires the use of Autoconf." LICENSE = "GPLv2" HOMEPAGE = "http://www.gnu.org/software/automake/" SECTION = "devel" -PR = "r4" +PR = "r5" SRC_URI = "${GNU_MIRROR}/automake/automake-${PV}.tar.bz2 " diff --git a/meta/recipes-devtools/automake/automake_1.11.1.bb b/meta/recipes-devtools/automake/automake_1.11.1.bb index 18450a0140..ff8353fe82 100644 --- a/meta/recipes-devtools/automake/automake_1.11.1.bb +++ b/meta/recipes-devtools/automake/automake_1.11.1.bb @@ -31,6 +31,7 @@ RDEPENDS_automake-native = "autoconf-native perl-native-runtime" PATHFIXPATCH = "file://path_prog_fixes.patch" PATHFIXPATCH_virtclass-native = "" +PATHFIXPATCH_virtclass-nativesdk = "" SRC_URI += "${PATHFIXPATCH} \ file://prefer-cpio-over-pax-for-ustar-archives.patch \ @@ -44,4 +45,4 @@ do_install () { install -d ${D}${datadir} } -BBCLASSEXTEND = "native" +BBCLASSEXTEND = "native nativesdk" diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc index 95e535a1b7..4dea613168 100644 --- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc +++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc @@ -5,7 +5,7 @@ PN = "binutils-cross-canadian-${TRANSLATED_TARGET_ARCH}" BPN = "binutils" DEPENDS = "flex-native bison-native virtual/${HOST_PREFIX}gcc-crosssdk virtual/libc-nativesdk zlib-nativesdk gettext-nativesdk" -EXTRA_OECONF = "--with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS} \ +EXTRA_OECONF = "--with-sysroot=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS} \ --program-prefix=${TARGET_PREFIX} \ --disable-werror" @@ -20,3 +20,5 @@ do_install () { rm -f ${D}${libdir}/libopcodes* rm -f ${D}${includedir}/*.h } + +BBCLASSEXTEND = "" diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1a.bb b/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1a.bb index e91e7dca3f..a49adedad6 100644 --- a/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1a.bb +++ b/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1a.bb @@ -1,3 +1,3 @@ require binutils_${PV}.bb require binutils-cross-canadian.inc -PR = "r1" +PR = "r2" diff --git a/meta/recipes-devtools/dosfstools/dosfstools-native_2.10.bb b/meta/recipes-devtools/dosfstools/dosfstools-native_2.10.bb deleted file mode 100644 index 91ff11faa6..0000000000 --- a/meta/recipes-devtools/dosfstools/dosfstools-native_2.10.bb +++ /dev/null @@ -1,19 +0,0 @@ -# dosfstools-native OE build file -# Copyright (C) 2004-2006, Advanced Micro Devices, Inc. All Rights Reserved -# Released under the MIT license (see packages/COPYING) - -require dosfstools_${PV}.bb - -PR="r5" - -SRC_URI = "ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-${PV}.src.tar.gz \ - file://mkdosfs-bootcode.patch \ - file://mkdosfs-dir.patch \ - file://alignment_hack.patch \ - file://dosfstools-2.10-kernel-2.6.patch \ - file://msdos_fat12_undefined.patch \ - file://dosfstools-msdos_fs-types.patch \ - file://include-linux-types.patch \ - file://2.6.20-syscall.patch" - -inherit native diff --git a/meta/recipes-devtools/dosfstools/dosfstools/2.6.20-syscall.patch b/meta/recipes-devtools/dosfstools/dosfstools/2.6.20-syscall.patch deleted file mode 100644 index 7cf2662d27..0000000000 --- a/meta/recipes-devtools/dosfstools/dosfstools/2.6.20-syscall.patch +++ /dev/null @@ -1,65 +0,0 @@ -Index: dosfstools-2.10/dosfsck/io.c -=================================================================== ---- dosfstools-2.10.orig/dosfsck/io.c 2007-06-07 16:15:52.000000000 +0200 -+++ dosfstools-2.10/dosfsck/io.c 2007-06-07 16:16:06.000000000 +0200 -@@ -42,28 +42,11 @@ - /* Use the _llseek system call directly, because there (once?) was a bug in - * the glibc implementation of it. */ - #include <linux/unistd.h> --#if defined __alpha || defined __ia64__ || defined __s390x__ || defined __x86_64__ || defined __ppc64__ - /* On alpha, the syscall is simply lseek, because it's a 64 bit system. */ - static loff_t llseek( int fd, loff_t offset, int whence ) - { - return lseek(fd, offset, whence); - } --#else --# ifndef __NR__llseek --# error _llseek system call not present --# endif --static _syscall5( int, _llseek, uint, fd, ulong, hi, ulong, lo, -- loff_t *, res, uint, wh ); -- --static loff_t llseek( int fd, loff_t offset, int whence ) --{ -- loff_t actual; -- -- if (_llseek(fd, offset>>32, offset&0xffffffff, &actual, whence) != 0) -- return (loff_t)-1; -- return actual; --} --#endif - - - void fs_open(char *path,int rw) -Index: dosfstools-2.10/mkdosfs/mkdosfs.c -=================================================================== ---- dosfstools-2.10.orig/mkdosfs/mkdosfs.c 2007-06-07 16:15:11.000000000 +0200 -+++ dosfstools-2.10/mkdosfs/mkdosfs.c 2007-06-07 16:15:30.000000000 +0200 -@@ -116,27 +116,11 @@ - /* Use the _llseek system call directly, because there (once?) was a bug in - * the glibc implementation of it. */ - #include <linux/unistd.h> --#if defined __alpha || defined __ia64__ || defined __s390x__ || defined __x86_64__ || defined __ppc64__ - /* On alpha, the syscall is simply lseek, because it's a 64 bit system. */ - static loff_t llseek( int fd, loff_t offset, int whence ) - { - return lseek(fd, offset, whence); - } --#else --# ifndef __NR__llseek --# error _llseek system call not present --# endif --static _syscall5( int, _llseek, uint, fd, ulong, hi, ulong, lo, -- loff_t *, res, uint, wh ); --static loff_t llseek( int fd, loff_t offset, int whence ) --{ -- loff_t actual; -- -- if (_llseek(fd, offset>>32, offset&0xffffffff, &actual, whence) != 0) -- return (loff_t)-1; -- return actual; --} --#endif - - #define ROUND_UP(value, divisor) (value + (divisor - (value % divisor))) / divisor - diff --git a/meta/recipes-devtools/dosfstools/dosfstools/alignment_hack.patch b/meta/recipes-devtools/dosfstools/dosfstools/alignment_hack.patch index e15060a6fe..b46b2db0a3 100644 --- a/meta/recipes-devtools/dosfstools/dosfstools/alignment_hack.patch +++ b/meta/recipes-devtools/dosfstools/dosfstools/alignment_hack.patch @@ -8,6 +8,10 @@ memcpy into an 16bit aligned -zecke +Upstream-Status: Inappropriate [licensing] +We're tracking an old release of dosfstools due to licensing issues. + +Signed-off-by: Scott Garman <scott.a.garman@intel.com> --- dosfstools/dosfsck/boot.c.orig 2003-05-15 19:32:23.000000000 +0200 +++ dosfstools/dosfsck/boot.c 2003-06-13 17:44:25.000000000 +0200 diff --git a/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-2.10-kernel-2.6.patch b/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-2.10-kernel-2.6.patch deleted file mode 100644 index 0c9230f7e4..0000000000 --- a/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-2.10-kernel-2.6.patch +++ /dev/null @@ -1,74 +0,0 @@ -Submitted By: Jim Gifford (jim at linuxfromscratch dot org) -Date: 2004-02-09 -Initial Package Version: 2.6 -Origin: Jim Gifford -Upstream-Status: Accepted -Description: Fixes Compile Issues with the 2.6 Kernel - ---- dosfstools-2.10/dosfsck/common.h.orig 2004-02-09 18:37:59.056737458 +0000 -+++ dosfstools-2.10/dosfsck/common.h 2004-02-09 18:38:18.333392952 +0000 -@@ -2,6 +2,13 @@ - - /* Written 1993 by Werner Almesberger */ - -+#include <linux/version.h> -+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) -+ #define __KERNEL__ -+ #include <asm/types.h> -+ #undef __KERNEL__ -+ #define MSDOS_FAT12 4084 /* maximum number of clusters in a 12 bit FAT */ -+#endif - - #ifndef _COMMON_H - #define _COMMON_H ---- dosfstools-2.10/dosfsck/file.c.orig 2004-02-09 18:40:52.016728845 +0000 -+++ dosfstools-2.10/dosfsck/file.c 2004-02-09 18:40:03.665117865 +0000 -@@ -15,6 +15,14 @@ - #define _LINUX_STAT_H /* hack to avoid inclusion of <linux/stat.h> */ - #define _LINUX_STRING_H_ /* hack to avoid inclusion of <linux/string.h>*/ - #define _LINUX_FS_H /* hack to avoid inclusion of <linux/fs.h> */ -+ -+#include <linux/version.h> -+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) -+ #define __KERNEL__ -+ #include <asm/types.h> -+ #undef __KERNEL__ -+#endif -+ - #include <linux/msdos_fs.h> - - #include "common.h" ---- dosfstools-2.10/dosfsck/dosfsck.h.orig 2004-02-09 18:57:11.022870974 +0000 -+++ dosfstools-2.10/dosfsck/dosfsck.h 2004-02-09 18:56:20.628614393 +0000 -@@ -13,6 +13,15 @@ - #define _LINUX_STAT_H /* hack to avoid inclusion of <linux/stat.h> */ - #define _LINUX_STRING_H_ /* hack to avoid inclusion of <linux/string.h>*/ - #define _LINUX_FS_H /* hack to avoid inclusion of <linux/fs.h> */ -+ -+#include <linux/version.h> -+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) -+ #define __KERNEL__ -+ #include <asm/types.h> -+ #include <asm/byteorder.h> -+ #undef __KERNEL__ -+#endif -+ - #include <linux/msdos_fs.h> - - /* 2.1 kernels use le16_to_cpu() type functions for CF_LE_W & Co., but don't ---- dosfstools-2.10/mkdosfs/mkdosfs.c.orig 2004-02-09 18:31:41.997157413 +0000 -+++ dosfstools-2.10/mkdosfs/mkdosfs.c 2004-02-09 18:34:07.311945252 +0000 -@@ -66,6 +66,13 @@ - #include <time.h> - #include <errno.h> - -+#include <linux/version.h> -+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) -+ #define __KERNEL__ -+ #include <asm/types.h> -+ #undef __KERNEL__ -+#endif -+ - #if __BYTE_ORDER == __BIG_ENDIAN - - #include <asm/byteorder.h> diff --git a/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch b/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch index e70a3ead2a..35abd1a2b1 100644 --- a/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch +++ b/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch @@ -1,3 +1,10 @@ +Ensure the __s8 type is properly defined. + +Upstream-Status: Inappropriate [licensing] +We're tracking an old release of dosfstools due to licensing issues. + +Signed-off-by: Scott Garman <scott.a.garman@intel.com> + --- dosfstools-2.10/dosfsck/dosfsck.h.org 2006-02-21 08:36:14.000000000 -0700 +++ dosfstools-2.10/dosfsck/dosfsck.h 2006-02-21 08:40:12.000000000 -0700 @@ -22,6 +22,14 @@ diff --git a/meta/recipes-devtools/dosfstools/dosfstools/include-linux-types.patch b/meta/recipes-devtools/dosfstools/dosfstools/include-linux-types.patch index 4bbd4e76e4..ab5c8cf8c3 100644 --- a/meta/recipes-devtools/dosfstools/dosfstools/include-linux-types.patch +++ b/meta/recipes-devtools/dosfstools/dosfstools/include-linux-types.patch @@ -5,6 +5,11 @@ include asm/types.h. To work around this patch mkdosfs.c to explicity include linux/types.h which will in turn pull in asm/types.h which defines these variables. +Upstream-Status: Inappropriate [licensing] +We're tracking an old release of dosfstools due to licensing issues. + +Signed-off-by: Scott Garman <scott.a.garman@intel.com> + --- dosfstools-2.10/mkdosfs/mkdosfs.c~ 2006-07-12 18:46:21.000000000 +1000 +++ dosfstools-2.10/mkdosfs/mkdosfs.c 2006-07-12 18:46:21.000000000 +1000 @@ -60,6 +60,7 @@ diff --git a/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-bootcode.patch b/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-bootcode.patch index 52be86284b..ae21bee78e 100644 --- a/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-bootcode.patch +++ b/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-bootcode.patch @@ -1,6 +1,14 @@ -diff -urN dosfstools-2.10.orig/mkdosfs/ChangeLog dosfstools-2.10/mkdosfs/ChangeLog ---- dosfstools-2.10.orig/mkdosfs/ChangeLog 1997-06-18 03:09:38.000000000 -0700 -+++ dosfstools-2.10/mkdosfs/ChangeLog 2004-08-02 20:57:57.734939816 -0700 +Add option to read in bootcode from a file. + +Upstream-Status: Inappropriate [licensing] +We're tracking an old release of dosfstools due to licensing issues. + +Signed-off-by: Scott Garman <scott.a.garman@intel.com> + +Index: dosfstools-2.11/mkdosfs/ChangeLog +=================================================================== +--- dosfstools-2.11.orig/mkdosfs/ChangeLog 1997-06-18 10:09:38.000000000 +0000 ++++ dosfstools-2.11/mkdosfs/ChangeLog 2011-12-06 12:14:23.634011558 +0000 @@ -1,3 +1,14 @@ +19th June 2003 Sam Bingner (sam@bingner.com) + @@ -16,10 +24,11 @@ diff -urN dosfstools-2.10.orig/mkdosfs/ChangeLog dosfstools-2.10/mkdosfs/ChangeL 28th January 1995 H. Peter Anvin (hpa@yggdrasil.com) Better algorithm to select cluster sizes on large filesystems. -diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.8 dosfstools-2.10/mkdosfs/mkdosfs.8 ---- dosfstools-2.10.orig/mkdosfs/mkdosfs.8 2003-05-15 11:28:28.000000000 -0700 -+++ dosfstools-2.10/mkdosfs/mkdosfs.8 2004-08-02 20:57:57.735939664 -0700 -@@ -40,6 +40,10 @@ +Index: dosfstools-2.11/mkdosfs/mkdosfs.8 +=================================================================== +--- dosfstools-2.11.orig/mkdosfs/mkdosfs.8 2004-02-25 19:36:07.000000000 +0000 ++++ dosfstools-2.11/mkdosfs/mkdosfs.8 2011-12-06 12:19:54.777888434 +0000 +@@ -44,6 +44,10 @@ .I message-file ] [ @@ -30,7 +39,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.8 dosfstools-2.10/mkdosfs/mkdosfs .B \-n .I volume-name ] -@@ -155,6 +159,18 @@ +@@ -165,6 +169,18 @@ carriage return-line feed combinations, and tabs have been expanded. If the filename is a hyphen (-), the text is taken from standard input. .TP @@ -49,21 +58,22 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.8 dosfstools-2.10/mkdosfs/mkdosfs .BI \-n " volume-name" Sets the volume name (label) of the filesystem. The volume name can be up to 11 characters long. The default is no label. -@@ -188,8 +204,9 @@ +@@ -198,8 +214,9 @@ simply will not support it ;) .SH AUTHOR Dave Hudson - <dave@humbug.demon.co.uk>; modified by Peter Anvin -<hpa@yggdrasil.com>. Fixes and additions by Roman Hodek --<Roman.Hodek@informatik.uni-erlangen.de> for Debian/GNU Linux. +-<roman@hodek.net> for Debian/GNU Linux. +<hpa@yggdrasil.com> and Sam Bingner <sam@bingner.com>. Fixes and +additions by Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de> +for Debian/GNU Linux. .SH ACKNOWLEDGEMENTS .B mkdosfs is based on code from -diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs.c ---- dosfstools-2.10.orig/mkdosfs/mkdosfs.c 2003-06-14 13:07:08.000000000 -0700 -+++ dosfstools-2.10/mkdosfs/mkdosfs.c 2004-08-02 20:57:57.736939512 -0700 +Index: dosfstools-2.11/mkdosfs/mkdosfs.c +=================================================================== +--- dosfstools-2.11.orig/mkdosfs/mkdosfs.c 2005-03-12 16:12:16.000000000 +0000 ++++ dosfstools-2.11/mkdosfs/mkdosfs.c 2011-12-06 12:27:55.121886076 +0000 @@ -24,6 +24,12 @@ - New options -A, -S, -C - Support for filesystems > 2GB @@ -77,7 +87,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs Copying: Copyright 1993, 1994 David Hudson (dave@humbug.demon.co.uk) -@@ -167,6 +173,8 @@ +@@ -153,6 +159,8 @@ #define FAT_BAD 0x0ffffff7 #define MSDOS_EXT_SIGN 0x29 /* extended boot sector signature */ @@ -86,7 +96,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs #define MSDOS_FAT12_SIGN "FAT12 " /* FAT12 filesystem signature */ #define MSDOS_FAT16_SIGN "FAT16 " /* FAT16 filesystem signature */ #define MSDOS_FAT32_SIGN "FAT32 " /* FAT32 filesystem signature */ -@@ -188,6 +196,8 @@ +@@ -175,6 +183,8 @@ #define BOOTCODE_SIZE 448 #define BOOTCODE_FAT32_SIZE 420 @@ -95,7 +105,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs /* __attribute__ ((packed)) is used on all structures to make gcc ignore any * alignments */ -@@ -215,7 +225,7 @@ +@@ -202,7 +212,7 @@ __u16 fat_length; /* sectors/FAT */ __u16 secs_track; /* sectors per track */ __u16 heads; /* number of heads */ @@ -104,7 +114,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs __u32 total_sect; /* number of sectors (if sectors == 0) */ union { struct { -@@ -298,6 +308,8 @@ +@@ -285,6 +295,8 @@ /* Global variables - the root of all evil :-) - see these and weep! */ @@ -113,7 +123,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs static char *program_name = "mkdosfs"; /* Name of the program */ static char *device_name = NULL; /* Name of the device on which to create the filesystem */ static int atari_format = 0; /* Use Atari variation of MS-DOS FS format */ -@@ -842,6 +854,12 @@ +@@ -837,6 +849,12 @@ vi->volume_id[2] = (unsigned char) ((volume_id & 0x00ff0000) >> 16); vi->volume_id[3] = (unsigned char) (volume_id >> 24); } @@ -126,16 +136,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs if (!atari_format) { memcpy(vi->volume_label, volume_name, 11); -@@ -886,7 +904,7 @@ - printf( "Using %d reserved sectors\n", reserved_sectors ); - bs.fats = (char) nr_fats; - if (!atari_format || size_fat == 32) -- bs.hidden = CT_LE_L(0); -+ bs.hidden = bs.secs_track; - else - /* In Atari format, hidden is a 16 bit field */ - memset( &bs.hidden, 0, 2 ); -@@ -1358,6 +1376,32 @@ +@@ -1362,6 +1380,32 @@ * dir area on FAT12/16, and the first cluster on FAT32. */ writebuf( (char *) root_dir, size_root_dir, "root directory" ); @@ -149,9 +150,9 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs + seekto( 512*2, "third sector" ); + if (backup_boot != 0) { + writebuf( template_boot_code+512*2, backup_boot*sector_size - 512*2, "data to backup boot" ); -+ seekto( backup_boot*sector_size, "backup boot sector" ); ++ seekto( backup_boot*sector_size, "backup boot sector" ); + writebuf( template_boot_code, 3, "backup jmpBoot" ); -+ seekto( backup_boot*sector_size+0x5a, "backup boot sector boot area" ); ++ seekto( backup_boot*sector_size+0x5a, "backup boot sector boot area" ); + writebuf( template_boot_code+0x5a, 420, "backup boot sector boot area" ); + seekto( (backup_boot+2)*sector_size, "sector following backup code" ); + writebuf( template_boot_code+(backup_boot+2)*sector_size, (reserved_sectors-backup_boot-2)*512, "remaining data" ); @@ -165,28 +166,28 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs + } + } + + if (blank_sector) free( blank_sector ); if (info_sector) free( info_sector ); free (root_dir); /* Free up the root directory space from setup_tables */ - free (fat); /* Free up the fat table space reserved during setup_tables */ -@@ -1371,7 +1415,7 @@ +@@ -1376,7 +1420,7 @@ { fatal_error("\ Usage: mkdosfs [-A] [-c] [-C] [-v] [-I] [-l bad-block-file] [-b backup-boot-sector]\n\ - [-m boot-msg-file] [-n volume-name] [-i volume-id]\n\ + [-m boot-msg-file] [-n volume-name] [-i volume-id] [-B bootcode]\n\ [-s sectors-per-cluster] [-S logical-sector-size] [-f number-of-FATs]\n\ - [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\ + [-h hidden-sectors] [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\ /dev/name [blocks]\n"); -@@ -1433,7 +1477,7 @@ +@@ -1439,7 +1483,7 @@ printf ("%s " VERSION " (" VERSION_DATE ")\n", program_name); -- while ((c = getopt (argc, argv, "AcCf:F:Ii:l:m:n:r:R:s:S:v")) != EOF) -+ while ((c = getopt (argc, argv, "AcCf:F:Ii:l:m:n:r:R:s:S:v:B:b")) != EOF) +- while ((c = getopt (argc, argv, "AbcCf:F:Ii:l:m:n:r:R:s:S:h:v")) != EOF) ++ while ((c = getopt (argc, argv, "AbcCf:F:Ii:l:m:n:r:R:s:S:v:B:")) != EOF) /* Scan the command line for options */ switch (c) { -@@ -1494,6 +1538,51 @@ +@@ -1509,6 +1553,51 @@ listfile = optarg; break; diff --git a/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch b/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch index 8f753b052c..3ba4711d12 100644 --- a/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch +++ b/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch @@ -1,6 +1,14 @@ -diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs.c ---- dosfstools-2.10.orig/mkdosfs/mkdosfs.c 2004-08-02 20:48:45.000000000 -0700 -+++ dosfstools-2.10/mkdosfs/mkdosfs.c 2004-08-02 20:49:44.296953792 -0700 +Add -d <directory> support to populate the image. + +Upstream-Status: Inappropriate [licensing] +We're tracking an old release of dosfstools due to licensing issues. + +Signed-off-by: Scott Garman <scott.a.garman@intel.com> + +Index: dosfstools-2.11/mkdosfs/mkdosfs.c +=================================================================== +--- dosfstools-2.11.orig/mkdosfs/mkdosfs.c 2011-12-06 12:27:55.000000000 +0000 ++++ dosfstools-2.11/mkdosfs/mkdosfs.c 2011-12-06 12:37:13.445950703 +0000 @@ -18,6 +18,10 @@ as a rule), and not the block. For example the boot block does not occupy a full cluster. @@ -19,18 +27,18 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs +#include <libgen.h> +#include <dirent.h> - #if __BYTE_ORDER == __BIG_ENDIAN - -@@ -124,6 +130,8 @@ - } - #endif + #include <linux/version.h> + #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) +@@ -110,6 +116,8 @@ + * sufficient (or even better :) for 64 bit offsets in the meantime */ + #define llseek lseek +#define ROUND_UP(value, divisor) (value + (divisor - (value % divisor))) / divisor + /* Constant definitions */ #define TRUE 1 /* Boolean constants */ -@@ -163,7 +171,6 @@ +@@ -149,7 +157,6 @@ #define ATTR_VOLUME 8 /* volume label */ #define ATTR_DIR 16 /* directory */ #define ATTR_ARCH 32 /* archived */ @@ -38,7 +46,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs #define ATTR_NONE 0 /* no attribute bits */ #define ATTR_UNUSED (ATTR_VOLUME | ATTR_ARCH | ATTR_SYS | ATTR_HIDDEN) /* attribute bits that are copied "as is" */ -@@ -258,6 +265,19 @@ +@@ -245,6 +252,19 @@ __u32 reserved2[4]; }; @@ -58,7 +66,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs struct msdos_dir_entry { char name[8], ext[3]; /* name and extension */ -@@ -306,6 +326,15 @@ +@@ -293,6 +313,15 @@ #define MESSAGE_OFFSET 29 /* Offset of message in above code */ @@ -74,7 +82,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs /* Global variables - the root of all evil :-) - see these and weep! */ static char *template_boot_code; /* Variable to store a full template boot sector in */ -@@ -339,6 +368,9 @@ +@@ -326,6 +355,9 @@ static int size_root_dir; /* Size of the root directory in bytes */ static int sectors_per_cluster = 0; /* Number of sectors per disk cluster */ static int root_dir_entries = 0; /* Number of root directory entries */ @@ -82,9 +90,9 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs +static int last_cluster_written = 0; + static char *blank_sector; /* Blank sector - all zeros */ + static int hidden_sectors = 0; /* Number of hidden sectors */ - -@@ -411,7 +443,6 @@ +@@ -399,7 +431,6 @@ } } @@ -92,7 +100,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs /* Mark a specified sector as having a particular value in it's FAT entry */ static void -@@ -1262,6 +1293,9 @@ +@@ -1266,6 +1297,9 @@ die ("unable to allocate space for root directory in memory"); } @@ -102,7 +110,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs memset(root_dir, 0, size_root_dir); if ( memcmp(volume_name, " ", 11) ) { -@@ -1310,11 +1344,11 @@ +@@ -1314,11 +1348,11 @@ } if (!(blank_sector = malloc( sector_size ))) @@ -117,7 +125,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs /* Write the new filesystem's data tables to wherever they're going to end up! */ #define error(str) \ -@@ -1336,7 +1370,7 @@ +@@ -1340,7 +1374,7 @@ do { \ int __size = (size); \ if (write (dev, buf, __size) != __size) \ @@ -126,7 +134,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs } while(0) -@@ -1407,6 +1441,452 @@ +@@ -1412,6 +1446,452 @@ free (fat); /* Free up the fat table space reserved during setup_tables */ } @@ -579,19 +587,16 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs /* Report the command usage and return a failure error code */ -@@ -1418,9 +1898,9 @@ +@@ -1423,7 +1903,7 @@ [-m boot-msg-file] [-n volume-name] [-i volume-id] [-B bootcode]\n\ [-s sectors-per-cluster] [-S logical-sector-size] [-f number-of-FATs]\n\ - [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\ + [-h hidden-sectors] [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\ - /dev/name [blocks]\n"); + [-d directory] /dev/name [blocks]\n"); } -- -+ + /* - * ++roman: On m68k, check if this is an Atari; if yes, turn on Atari variant - * of MS-DOS filesystem by default. -@@ -1458,6 +1938,8 @@ +@@ -1463,6 +1943,8 @@ int c; char *tmp; char *listfile = NULL; @@ -600,27 +605,27 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs FILE *msgfile; struct stat statbuf; int i = 0, pos, ch; -@@ -1477,7 +1959,7 @@ +@@ -1483,7 +1965,7 @@ printf ("%s " VERSION " (" VERSION_DATE ")\n", program_name); -- while ((c = getopt (argc, argv, "AcCf:F:Ii:l:m:n:r:R:s:S:v:B:b")) != EOF) -+ while ((c = getopt (argc, argv, "AcCd:f:F:Ii:l:m:n:r:R:s:S:v:B:b")) != EOF) +- while ((c = getopt (argc, argv, "AbcCf:F:Ii:l:m:n:r:R:s:S:v:B:")) != EOF) ++ while ((c = getopt (argc, argv, "AbcCd:f:F:Ii:l:m:n:r:R:s:S:v:B:")) != EOF) /* Scan the command line for options */ switch (c) { -@@ -1502,6 +1984,10 @@ +@@ -1508,6 +1990,10 @@ create = TRUE; break; -+ case 'd': ++ case 'd': + dirname = optarg; + break; + case 'f': /* f : Choose number of FATs */ nr_fats = (int) strtol (optarg, &tmp, 0); if (*tmp || nr_fats < 1 || nr_fats > 4) -@@ -1796,8 +2282,10 @@ +@@ -1811,8 +2297,10 @@ else if (listfile) get_list_blocks (listfile); diff --git a/meta/recipes-devtools/dosfstools/dosfstools/msdos_fat12_undefined.patch b/meta/recipes-devtools/dosfstools/dosfstools/msdos_fat12_undefined.patch index 4987aa3019..11e8a7594b 100644 --- a/meta/recipes-devtools/dosfstools/dosfstools/msdos_fat12_undefined.patch +++ b/meta/recipes-devtools/dosfstools/dosfstools/msdos_fat12_undefined.patch @@ -1,3 +1,10 @@ +Fix a compilation error due to undefined MSDOS_FAT12. + +Upstream-Status: Inappropriate [licensing] +We're tracking an old release of dosfstools due to licensing issues. + +Signed-off-by: Scott Garman <scott.a.garman@intel.com> + --- dosfstools-2.10/dosfsck/boot.c.orig 2004-10-15 08:51:42.394725176 -0600 +++ dosfstools-2.10/dosfsck/boot.c 2004-10-15 08:49:16.776862456 -0600 @@ -14,6 +14,9 @@ diff --git a/meta/recipes-devtools/dosfstools/dosfstools/nofat32_autoselect.patch b/meta/recipes-devtools/dosfstools/dosfstools/nofat32_autoselect.patch new file mode 100644 index 0000000000..21ebc1052c --- /dev/null +++ b/meta/recipes-devtools/dosfstools/dosfstools/nofat32_autoselect.patch @@ -0,0 +1,27 @@ +FAT32 appears to be broken when used with the -d option to populate the msdos +image. This disables the FAT32 autoselection code which means we don't get +broken images with the -d option. It can still be enabled on the commandline +at the users own risk. This changes us back to the 2.10 version's behaviour +which was known to work well even with large images. + +Upstream Status: Inapprioriate [depends on other patches we apply] + +RP 2011/12/13 + +Index: dosfstools-2.11/mkdosfs/mkdosfs.c +=================================================================== +--- dosfstools-2.11.orig/mkdosfs/mkdosfs.c 2011-12-13 13:54:37.538509391 +0000 ++++ dosfstools-2.11/mkdosfs/mkdosfs.c 2011-12-13 13:55:10.258508631 +0000 +@@ -808,10 +808,12 @@ + bs.media = (char) 0xf8; /* Set up the media descriptor for a hard drive */ + bs.dir_entries[0] = (char) 0; /* Default to 512 entries */ + bs.dir_entries[1] = (char) 2; ++/* + if (!size_fat && blocks*SECTORS_PER_BLOCK > 1064960) { + if (verbose) printf("Auto-selecting FAT32 for large filesystem\n"); + size_fat = 32; + } ++*/ + if (size_fat == 32) { + /* For FAT32, try to do the same as M$'s format command: + * fs size < 256M: 0.5k clusters diff --git a/meta/recipes-devtools/dosfstools/dosfstools_2.10.bb b/meta/recipes-devtools/dosfstools/dosfstools_2.10.bb deleted file mode 100644 index 1beb5ddc15..0000000000 --- a/meta/recipes-devtools/dosfstools/dosfstools_2.10.bb +++ /dev/null @@ -1,21 +0,0 @@ -# dosfstools OE build file -# Copyright (C) 2004-2006, Advanced Micro Devices, Inc. All Rights Reserved -# Released under the MIT license (see packages/COPYING) - -DESCRIPTION = "DOS FAT Filesystem Utilities" - -SECTION = "base" -LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://mkdosfs/COPYING;md5=cbe67f08d6883bff587f615f0cc81aa8" -PR = "r2" - -SRC_URI = "ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-${PV}.src.tar.gz \ - file://alignment_hack.patch \ - file://dosfstools-2.10-kernel-2.6.patch \ - file://msdos_fat12_undefined.patch \ - file://include-linux-types.patch" - -do_install () { - oe_runmake "PREFIX=${D}" "SBINDIR=${D}${sbindir}" \ - "MANDIR=${D}${mandir}/man8" install -} diff --git a/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb b/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb index 944d873db7..66eeb7c71b 100644 --- a/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb +++ b/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb @@ -7,12 +7,16 @@ DESCRIPTION = "DOS FAT Filesystem Utilities" SECTION = "base" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://mkdosfs/COPYING;md5=cbe67f08d6883bff587f615f0cc81aa8" -PR = "r0" +PR = "r3" SRC_URI = "ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-${PV}.src.tar.gz \ - file://alignment_hack.patch \ + file://mkdosfs-bootcode.patch \ + file://mkdosfs-dir.patch \ + file://alignment_hack.patch \ file://msdos_fat12_undefined.patch \ - file://include-linux-types.patch" + file://dosfstools-msdos_fs-types.patch \ + file://include-linux-types.patch \ + file://nofat32_autoselect.patch " SRC_URI[md5sum] = "407d405ade410f7597d364ab5dc8c9f6" SRC_URI[sha256sum] = "0eac6d12388b3d9ed78684529c1b0d9346fa2abbe406c4d4a3eb5a023c98a484" @@ -21,3 +25,5 @@ do_install () { oe_runmake "PREFIX=${D}" "SBINDIR=${D}${sbindir}" \ "MANDIR=${D}${mandir}/man8" install } + +BBCLASSEXTEND = "native" diff --git a/meta/recipes-devtools/dpkg/dpkg.inc b/meta/recipes-devtools/dpkg/dpkg.inc index 8c2511dc43..041737b1d2 100644 --- a/meta/recipes-devtools/dpkg/dpkg.inc +++ b/meta/recipes-devtools/dpkg/dpkg.inc @@ -2,7 +2,7 @@ DESCRIPTION = "Package maintenance system for Debian." LICENSE = "GPL" SECTION = "base" -INC_PR = "r5" +INC_PR = "r11" SRC_URI = "${DEBIAN_MIRROR}/main/d/dpkg/dpkg_${PV}.tar.bz2 \ file://ignore_extra_fields.patch" @@ -18,8 +18,25 @@ PARALLEL_MAKE = "" inherit autotools gettext perlnative -DPKG_INIT_POSITION = "98" +export PERL_LIBDIR = "${libdir}/perl" +PERL_LIBDIR_virtclass-native = "${libdir}/perl-native/perl" +EXTRA_OECONF = "--without-static-progs \ + --without-dselect \ + --with-start-stop-daemon \ + --with-zlib \ + --with-bz2lib \ + --without-selinux \ + --without-sgml-doc" + +do_configure () { + echo >> m4/compiler.m4 + sed -i -e 's#PERL_LIBDIR=.*$#PERL_LIBDIR="${libdir}/perl"#' ${S}/configure + autotools_do_configure +} + + +DPKG_INIT_POSITION ?= "98" do_install_prepend () { install -d ${D}/${sysconfdir}/rcS.d # this happens at S98 where our good 'ole packages script used to run @@ -30,7 +47,27 @@ rm -f ${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}configure chmod 0755 ${D}/${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}configure } -do_configure () { - echo >> m4/compiler.m4 - autotools_do_configure +do_install_append () { + if [ "${PN}" = "dpkg-native" ]; then + # update-alternatives doesn't have an offline mode + rm ${D}${bindir}/update-alternatives + else + mv ${D}${bindir}/update-alternatives ${D}${sbindir} + fi } + +PROV = "virtual/update-alternatives" +PROV_virtclass-native = "" + +PROVIDES += "${PROV}" + +PACKAGES =+ "update-alternatives-dpkg" +FILES_update-alternatives-dpkg = "${sbindir}/update-alternatives ${localstatedir}/lib/dpkg/alternatives ${sysconfdir}/alternatives" +RPROVIDES_update-alternatives-dpkg += "update-alternatives" + +PACKAGES += "${PN}-perl" +FILES_${PN}-perl = "${libdir}/perl" + +BBCLASSEXTEND = "native" + + diff --git a/meta/recipes-devtools/dpkg/dpkg/perllibdir.patch b/meta/recipes-devtools/dpkg/dpkg/perllibdir.patch new file mode 100644 index 0000000000..45973f012d --- /dev/null +++ b/meta/recipes-devtools/dpkg/dpkg/perllibdir.patch @@ -0,0 +1,22 @@ +We want to be able to set PERL_LIBDIR from the environment. This +hardcoded assignment prevents us from doing so and obtains an +incorrect value. + +Upstream-Status: Inappropriate [in this form at least] + +RP 14/11/2011 + +Index: dpkg-1.15.8.7/m4/dpkg-progs.m4 +=================================================================== +--- dpkg-1.15.8.7.orig/m4/dpkg-progs.m4 2011-11-14 17:32:21.252053239 +0000 ++++ dpkg-1.15.8.7/m4/dpkg-progs.m4 2011-11-14 17:32:55.180052455 +0000 +@@ -9,9 +9,6 @@ + [AC_ARG_VAR([PERL], [Perl interpreter])dnl + AC_PATH_PROG([PERL], [perl], [/usr/bin/perl])dnl + AC_ARG_VAR([PERL_LIBDIR], [Perl library directory])dnl +-PERL_LIBDIR=$($PERL -MConfig -e 'my $r = $Config{vendorlibexp}; +- $r =~ s/$Config{vendorprefixexp}/\$(prefix)/; +- print $r')dnl + ])# DPKG_PROG_PERL + + # DPKG_PROG_PO4A diff --git a/meta/recipes-devtools/dpkg/dpkg_1.15.8.7.bb b/meta/recipes-devtools/dpkg/dpkg_1.15.8.7.bb index 99197c0b7f..f1a0eebcd5 100644 --- a/meta/recipes-devtools/dpkg/dpkg_1.15.8.7.bb +++ b/meta/recipes-devtools/dpkg/dpkg_1.15.8.7.bb @@ -3,23 +3,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" SRC_URI += "file://noman.patch \ file://check_snprintf.patch \ - file://check_version.patch" + file://check_version.patch \ + file://perllibdir.patch" SRC_URI[md5sum] = "d1731d4147c1ea3b537a4d094519a6dc" SRC_URI[sha256sum] = "1ec1376471b04717a4497e5d7a27cd545248c92116898ce0c53ced8ea94267b5" -PR = "${INC_PR}.0" +PR = "${INC_PR}.1" -EXTRA_OECONF = "--without-static-progs \ - --without-dselect \ - --with-start-stop-daemon \ - --with-zlib \ - --with-bz2lib \ - --without-selinux \ - --without-sgml-doc" - -BBCLASSEXTEND = "native" - -do_install_append () { - rm ${D}${bindir}/update-alternatives -} diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb index ea0782dea4..1fca7b9137 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb @@ -1,6 +1,6 @@ require e2fsprogs.inc -PR = "r1" +PR = "r2" SRC_URI += "file://quotefix.patch \ file://acinclude.m4" @@ -51,5 +51,6 @@ FILES_libcomerr = "${libdir}/libcom_err.so.*" FILES_libss = "${libdir}/libss.so.*" FILES_libe2p = "${libdir}/libe2p.so.*" FILES_libext2fs = "${libdir}/e2initrd_helper ${libdir}/libext2fs.so.*" +FILES_${PN}-dev += "${datadir}/*/*.awk ${datadir}/*/*.sed" BBCLASSEXTEND = "native" diff --git a/meta/recipes-devtools/gcc/gcc-4.5.1.inc b/meta/recipes-devtools/gcc/gcc-4.5.1.inc index f2991f286c..839529e5b9 100644 --- a/meta/recipes-devtools/gcc/gcc-4.5.1.inc +++ b/meta/recipes-devtools/gcc/gcc-4.5.1.inc @@ -1,6 +1,6 @@ require gcc-common.inc -PR = "r9" +PR = "r12" DEPENDS =+ "mpfr gmp libmpc elfutils" NATIVEDEPS = "mpfr-native gmp-native gettext-native libmpc-native elfutils-native" diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc index f7bcf30f1b..d96394a0f1 100644 --- a/meta/recipes-devtools/gcc/gcc-4.6.inc +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc @@ -1,6 +1,6 @@ require gcc-common.inc -PR = "r10" +PR = "r17" # Third digit in PV should be incremented after a minor release # happens from this branch on gcc e.g. currently its 4.6.0 @@ -8,7 +8,7 @@ PR = "r10" # on branch then PV should be incremented to 4.6.1+svnr${SRCPV} # to reflect that change -PV = "4.6.1+svnr${SRCPV}" +PV = "4.6.2+svnr${SRCPV}" # BINV should be incremented after updating to a revision # after a minor gcc release (e.g. 4.6.1 or 4.6.2) has been made @@ -16,9 +16,9 @@ PV = "4.6.1+svnr${SRCPV}" # 4.6.1 then the value below will have 2 which will mean 4.6.2 # which will be next minor release and so on. -BINV = "4.6.1" +BINV = "4.6.3" -SRCREV = 175454 +SRCREV = 181430 BRANCH = "gcc-4_6-branch" FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.6' ], d)}" @@ -68,6 +68,9 @@ SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \ file://use-defaults.h-and-t-oe-in-B.patch \ file://powerpc-e5500.patch \ file://fix-for-ice-50099.patch \ + file://pr46934.patch \ + file://pr32219.patch \ + file://pr47551.patch \ " SRC_URI_append_sh3 = " file://sh3-installfix-fixheaders.patch " diff --git a/meta/recipes-devtools/gcc/gcc-4.6/pr32219.patch b/meta/recipes-devtools/gcc/gcc-4.6/pr32219.patch new file mode 100644 index 0000000000..e310080a30 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.6/pr32219.patch @@ -0,0 +1,71 @@ +Hi, + +As suggested by richi. +regtested on i686-linux-gnu with all default languages and no regressions. +Ok for trunk? + +gcc/ChangeLog +2010-03-15 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> + + PR target/32219 + * varasm.c (default_binds_local_p_1): Weak data is not local. + +gcc/testsuite/ChangeLog +2010-03-15 Bernhard Reutner-Fischer <aldot@gcc.gnu.org> + + PR target/32219 + * gcc.dg/visibility-21.c: New test. + +Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> +--- + gcc/testsuite/gcc.dg/visibility-21.c | 14 ++++++++++++++ + gcc/varasm.c | 8 ++++---- + 2 files changed, 18 insertions(+), 4 deletions(-) + create mode 100644 gcc/testsuite/gcc.dg/visibility-21.c + +Index: gcc-4_6-branch/gcc/testsuite/gcc.dg/visibility-21.c +=================================================================== +--- /dev/null 1970-01-01 00:00:00.000000000 +0000 ++++ gcc-4_6-branch/gcc/testsuite/gcc.dg/visibility-21.c 2011-10-18 17:11:33.224827436 -0700 +@@ -0,0 +1,14 @@ ++/* PR target/32219 */ ++/* { dg-do run } */ ++/* { dg-require-visibility "" } */ ++/* { dg-options "-fPIC" { target fpic } } */ ++ ++extern void f() __attribute__((weak,visibility("hidden"))); ++extern int puts( char const* ); ++int main() ++{ ++ if (f) ++ f(); ++ return 0; ++} ++ +Index: gcc-4_6-branch/gcc/varasm.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/varasm.c 2011-09-16 19:58:21.000000000 -0700 ++++ gcc-4_6-branch/gcc/varasm.c 2011-10-18 17:19:06.431074788 -0700 +@@ -6760,6 +6760,10 @@ + /* Static variables are always local. */ + else if (! TREE_PUBLIC (exp)) + local_p = true; ++ /* hidden weak can't be overridden by something non-local, all ++ that is possible is that it is not defined at all. */ ++ else if (DECL_WEAK (exp)) ++ local_p = false; + /* A variable is local if the user has said explicitly that it will + be. */ + else if ((DECL_VISIBILITY_SPECIFIED (exp) +@@ -6773,11 +6777,6 @@ + local. */ + else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT) + local_p = true; +- /* Default visibility weak data can be overridden by a strong symbol +- in another module and so are not local. */ +- else if (DECL_WEAK (exp) +- && !resolved_locally) +- local_p = false; + /* If PIC, then assume that any global name can be overridden by + symbols resolved from other modules. */ + else if (shlib) diff --git a/meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch b/meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch new file mode 100644 index 0000000000..afd3eef8f0 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.6/pr46934.patch @@ -0,0 +1,392 @@ +2011-09-19 chengbin <bin.cheng@arm.com> + + Backport r174035 from mainline + 2011-05-22 Tom de Vries <tom@codesourcery.com> + + PR middle-end/48689 + * fold-const.c (fold_checksum_tree): Guard TREE_CHAIN use with + CODE_CONTAINS_STRUCT (TS_COMMON). + + Backport r172297 from mainline + 2011-04-11 Chung-Lin Tang <cltang@codesourcery.com> + Richard Earnshaw <rearnsha@arm.com> + + PR target/48250 + * config/arm/arm.c (arm_legitimize_reload_address): Update cases + to use sign-magnitude offsets. Reject unsupported unaligned + cases. Add detailed description in comments. + * config/arm/arm.md (reload_outdf): Disable for ARM mode; change + condition from TARGET_32BIT to TARGET_ARM. + + Backport r171978 from mainline + 2011-04-05 Tom de Vries <tom@codesourcery.com> + + PR target/43920 + * config/arm/arm.h (BRANCH_COST): Set to 1 for Thumb-2 when optimizing + for size. + + Backport r171632 from mainline + 2011-03-28 Richard Sandiford <richard.sandiford@linaro.org> + + * builtins.c (expand_builtin_memset_args): Use gen_int_mode + instead of GEN_INT. + + Backport r171379 from mainline + 2011-03-23 Chung-Lin Tang <cltang@codesourcery.com> + + PR target/46934 + * config/arm/arm.md (casesi): Use the gen_int_mode() function + to subtract lower bound instead of GEN_INT(). + + Backport r171251 from mainline + 2011-03-21 Daniel Jacobowitz <dan@codesourcery.com> + + * config/arm/unwind-arm.c (__gnu_unwind_pr_common): Correct test + for barrier handlers. + + Backport r171096 from mainline + 2011-03-17 Chung-Lin Tang <cltang@codesourcery.com> + + PR target/43872 + * config/arm/arm.c (arm_get_frame_offsets): Adjust early + return condition with !cfun->calls_alloca. + +Index: gcc-4_6-branch/gcc/builtins.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/builtins.c 2011-10-17 17:45:32.050502963 -0700 ++++ gcc-4_6-branch/gcc/builtins.c 2011-10-17 17:46:11.154696878 -0700 +@@ -3972,6 +3972,7 @@ + { + tree fndecl, fn; + enum built_in_function fcode; ++ enum machine_mode val_mode; + char c; + unsigned int dest_align; + rtx dest_mem, dest_addr, len_rtx; +@@ -4006,14 +4007,14 @@ + + len_rtx = expand_normal (len); + dest_mem = get_memory_rtx (dest, len); ++ val_mode = TYPE_MODE (unsigned_char_type_node); + + if (TREE_CODE (val) != INTEGER_CST) + { + rtx val_rtx; + + val_rtx = expand_normal (val); +- val_rtx = convert_to_mode (TYPE_MODE (unsigned_char_type_node), +- val_rtx, 0); ++ val_rtx = convert_to_mode (val_mode, val_rtx, 0); + + /* Assume that we can memset by pieces if we can store + * the coefficients by pieces (in the required modes). +@@ -4024,8 +4025,7 @@ + builtin_memset_read_str, &c, dest_align, + true)) + { +- val_rtx = force_reg (TYPE_MODE (unsigned_char_type_node), +- val_rtx); ++ val_rtx = force_reg (val_mode, val_rtx); + store_by_pieces (dest_mem, tree_low_cst (len, 1), + builtin_memset_gen_str, val_rtx, dest_align, + true, 0); +@@ -4051,7 +4051,8 @@ + true)) + store_by_pieces (dest_mem, tree_low_cst (len, 1), + builtin_memset_read_str, &c, dest_align, true, 0); +- else if (!set_storage_via_setmem (dest_mem, len_rtx, GEN_INT (c), ++ else if (!set_storage_via_setmem (dest_mem, len_rtx, ++ gen_int_mode (c, val_mode), + dest_align, expected_align, + expected_size)) + goto do_libcall; +Index: gcc-4_6-branch/gcc/config/arm/arm.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/config/arm/arm.c 2011-10-17 17:45:41.914551883 -0700 ++++ gcc-4_6-branch/gcc/config/arm/arm.c 2011-10-17 17:48:35.447412371 -0700 +@@ -6406,23 +6406,126 @@ + HOST_WIDE_INT val = INTVAL (XEXP (*p, 1)); + HOST_WIDE_INT low, high; + +- if (mode == DImode || (mode == DFmode && TARGET_SOFT_FLOAT)) +- low = ((val & 0xf) ^ 0x8) - 0x8; +- else if (TARGET_MAVERICK && TARGET_HARD_FLOAT) +- /* Need to be careful, -256 is not a valid offset. */ +- low = val >= 0 ? (val & 0xff) : -((-val) & 0xff); +- else if (mode == SImode +- || (mode == SFmode && TARGET_SOFT_FLOAT) +- || ((mode == HImode || mode == QImode) && ! arm_arch4)) +- /* Need to be careful, -4096 is not a valid offset. */ +- low = val >= 0 ? (val & 0xfff) : -((-val) & 0xfff); +- else if ((mode == HImode || mode == QImode) && arm_arch4) +- /* Need to be careful, -256 is not a valid offset. */ +- low = val >= 0 ? (val & 0xff) : -((-val) & 0xff); +- else if (GET_MODE_CLASS (mode) == MODE_FLOAT +- && TARGET_HARD_FLOAT && TARGET_FPA) +- /* Need to be careful, -1024 is not a valid offset. */ +- low = val >= 0 ? (val & 0x3ff) : -((-val) & 0x3ff); ++ /* Detect coprocessor load/stores. */ ++ bool coproc_p = ((TARGET_HARD_FLOAT ++ && (TARGET_VFP || TARGET_FPA || TARGET_MAVERICK) ++ && (mode == SFmode || mode == DFmode ++ || (mode == DImode && TARGET_MAVERICK))) ++ || (TARGET_REALLY_IWMMXT ++ && VALID_IWMMXT_REG_MODE (mode)) ++ || (TARGET_NEON ++ && (VALID_NEON_DREG_MODE (mode) ++ || VALID_NEON_QREG_MODE (mode)))); ++ ++ /* For some conditions, bail out when lower two bits are unaligned. */ ++ if ((val & 0x3) != 0 ++ /* Coprocessor load/store indexes are 8-bits + '00' appended. */ ++ && (coproc_p ++ /* For DI, and DF under soft-float: */ ++ || ((mode == DImode || mode == DFmode) ++ /* Without ldrd, we use stm/ldm, which does not ++ fair well with unaligned bits. */ ++ && (! TARGET_LDRD ++ /* Thumb-2 ldrd/strd is [-1020,+1020] in steps of 4. */ ++ || TARGET_THUMB2)))) ++ return false; ++ ++ /* When breaking down a [reg+index] reload address into [(reg+high)+low], ++ of which the (reg+high) gets turned into a reload add insn, ++ we try to decompose the index into high/low values that can often ++ also lead to better reload CSE. ++ For example: ++ ldr r0, [r2, #4100] // Offset too large ++ ldr r1, [r2, #4104] // Offset too large ++ ++ is best reloaded as: ++ add t1, r2, #4096 ++ ldr r0, [t1, #4] ++ add t2, r2, #4096 ++ ldr r1, [t2, #8] ++ ++ which post-reload CSE can simplify in most cases to eliminate the ++ second add instruction: ++ add t1, r2, #4096 ++ ldr r0, [t1, #4] ++ ldr r1, [t1, #8] ++ ++ The idea here is that we want to split out the bits of the constant ++ as a mask, rather than as subtracting the maximum offset that the ++ respective type of load/store used can handle. ++ ++ When encountering negative offsets, we can still utilize it even if ++ the overall offset is positive; sometimes this may lead to an immediate ++ that can be constructed with fewer instructions. ++ For example: ++ ldr r0, [r2, #0x3FFFFC] ++ ++ This is best reloaded as: ++ add t1, r2, #0x400000 ++ ldr r0, [t1, #-4] ++ ++ The trick for spotting this for a load insn with N bits of offset ++ (i.e. bits N-1:0) is to look at bit N; if it is set, then chose a ++ negative offset that is going to make bit N and all the bits below ++ it become zero in the remainder part. ++ ++ The SIGN_MAG_LOW_ADDR_BITS macro below implements this, with respect ++ to sign-magnitude addressing (i.e. separate +- bit, or 1's complement), ++ used in most cases of ARM load/store instructions. */ ++ ++#define SIGN_MAG_LOW_ADDR_BITS(VAL, N) \ ++ (((VAL) & ((1 << (N)) - 1)) \ ++ ? (((VAL) & ((1 << ((N) + 1)) - 1)) ^ (1 << (N))) - (1 << (N)) \ ++ : 0) ++ ++ if (coproc_p) ++ low = SIGN_MAG_LOW_ADDR_BITS (val, 10); ++ else if (GET_MODE_SIZE (mode) == 8) ++ { ++ if (TARGET_LDRD) ++ low = (TARGET_THUMB2 ++ ? SIGN_MAG_LOW_ADDR_BITS (val, 10) ++ : SIGN_MAG_LOW_ADDR_BITS (val, 8)); ++ else ++ /* For pre-ARMv5TE (without ldrd), we use ldm/stm(db/da/ib) ++ to access doublewords. The supported load/store offsets are ++ -8, -4, and 4, which we try to produce here. */ ++ low = ((val & 0xf) ^ 0x8) - 0x8; ++ } ++ else if (GET_MODE_SIZE (mode) < 8) ++ { ++ /* NEON element load/stores do not have an offset. */ ++ if (TARGET_NEON_FP16 && mode == HFmode) ++ return false; ++ ++ if (TARGET_THUMB2) ++ { ++ /* Thumb-2 has an asymmetrical index range of (-256,4096). ++ Try the wider 12-bit range first, and re-try if the result ++ is out of range. */ ++ low = SIGN_MAG_LOW_ADDR_BITS (val, 12); ++ if (low < -255) ++ low = SIGN_MAG_LOW_ADDR_BITS (val, 8); ++ } ++ else ++ { ++ if (mode == HImode || mode == HFmode) ++ { ++ if (arm_arch4) ++ low = SIGN_MAG_LOW_ADDR_BITS (val, 8); ++ else ++ { ++ /* The storehi/movhi_bytes fallbacks can use only ++ [-4094,+4094] of the full ldrb/strb index range. */ ++ low = SIGN_MAG_LOW_ADDR_BITS (val, 12); ++ if (low == 4095 || low == -4095) ++ return false; ++ } ++ } ++ else ++ low = SIGN_MAG_LOW_ADDR_BITS (val, 12); ++ } ++ } + else + return false; + +@@ -15415,7 +15518,10 @@ + offsets->soft_frame = offsets->saved_regs + CALLER_INTERWORKING_SLOT_SIZE; + /* A leaf function does not need any stack alignment if it has nothing + on the stack. */ +- if (leaf && frame_size == 0) ++ if (leaf && frame_size == 0 ++ /* However if it calls alloca(), we have a dynamically allocated ++ block of BIGGEST_ALIGNMENT on stack, so still do stack alignment. */ ++ && ! cfun->calls_alloca) + { + offsets->outgoing_args = offsets->soft_frame; + offsets->locals_base = offsets->soft_frame; +Index: gcc-4_6-branch/gcc/config/arm/arm.h +=================================================================== +--- gcc-4_6-branch.orig/gcc/config/arm/arm.h 2011-10-17 17:45:41.910551858 -0700 ++++ gcc-4_6-branch/gcc/config/arm/arm.h 2011-10-17 17:48:35.447412371 -0700 +@@ -2041,7 +2041,8 @@ + /* Try to generate sequences that don't involve branches, we can then use + conditional instructions */ + #define BRANCH_COST(speed_p, predictable_p) \ +- (TARGET_32BIT ? 4 : (optimize > 0 ? 2 : 0)) ++ (TARGET_32BIT ? (TARGET_THUMB2 && !speed_p ? 1 : 4) \ ++ : (optimize > 0 ? 2 : 0)) + + /* Position Independent Code. */ + /* We decide which register to use based on the compilation options and +Index: gcc-4_6-branch/gcc/config/arm/arm.md +=================================================================== +--- gcc-4_6-branch.orig/gcc/config/arm/arm.md 2011-10-17 17:46:11.002696119 -0700 ++++ gcc-4_6-branch/gcc/config/arm/arm.md 2011-10-17 17:46:11.202697111 -0700 +@@ -6187,7 +6187,7 @@ + [(match_operand:DF 0 "arm_reload_memory_operand" "=o") + (match_operand:DF 1 "s_register_operand" "r") + (match_operand:SI 2 "s_register_operand" "=&r")] +- "TARGET_32BIT" ++ "TARGET_THUMB2" + " + { + enum rtx_code code = GET_CODE (XEXP (operands[0], 0)); +@@ -8359,7 +8359,8 @@ + rtx reg = gen_reg_rtx (SImode); + + emit_insn (gen_addsi3 (reg, operands[0], +- GEN_INT (-INTVAL (operands[1])))); ++ gen_int_mode (-INTVAL (operands[1]), ++ SImode))); + operands[0] = reg; + } + +Index: gcc-4_6-branch/gcc/config/arm/unwind-arm.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/config/arm/unwind-arm.c 2011-10-17 17:45:41.390549278 -0700 ++++ gcc-4_6-branch/gcc/config/arm/unwind-arm.c 2011-10-17 17:46:11.000000000 -0700 +@@ -1196,8 +1196,6 @@ + ucbp->barrier_cache.bitpattern[4] = (_uw) &data[1]; + + if (data[0] & uint32_highbit) +- phase2_call_unexpected_after_unwind = 1; +- else + { + data += rtti_count + 1; + /* Setup for entry to the handler. */ +@@ -1207,6 +1205,8 @@ + _Unwind_SetGR (context, 0, (_uw) ucbp); + return _URC_INSTALL_CONTEXT; + } ++ else ++ phase2_call_unexpected_after_unwind = 1; + } + if (data[0] & uint32_highbit) + data++; +Index: gcc-4_6-branch/gcc/fold-const.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/fold-const.c 2011-10-17 17:45:32.050502963 -0700 ++++ gcc-4_6-branch/gcc/fold-const.c 2011-10-17 17:46:11.178696990 -0700 +@@ -13788,7 +13788,8 @@ + if (TREE_CODE_CLASS (code) != tcc_type + && TREE_CODE_CLASS (code) != tcc_declaration + && code != TREE_LIST +- && code != SSA_NAME) ++ && code != SSA_NAME ++ && CODE_CONTAINS_STRUCT (code, TS_COMMON)) + fold_checksum_tree (TREE_CHAIN (expr), ctx, ht); + switch (TREE_CODE_CLASS (code)) + { +Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr40887.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr40887.c 2011-06-24 08:13:47.000000000 -0700 ++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr40887.c 2011-10-17 17:46:11.182697014 -0700 +@@ -1,5 +1,6 @@ + /* { dg-options "-O2 -march=armv5te" } */ + /* { dg-final { scan-assembler "blx" } } */ ++/* { dg-prune-output "switch .* conflicts with" } */ + + int (*indirect_func)(); + +Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr42575.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr42575.c 2011-06-24 08:13:47.000000000 -0700 ++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr42575.c 2011-10-17 17:46:11.182697014 -0700 +@@ -1,4 +1,4 @@ +-/* { dg-options "-O2 -march=armv7-a" } */ ++/* { dg-options "-O2" } */ + /* Make sure RA does good job allocating registers and avoids + unnecessary moves. */ + /* { dg-final { scan-assembler-not "mov" } } */ +Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr43698.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr43698.c 2011-06-24 08:13:47.000000000 -0700 ++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr43698.c 2011-10-17 17:46:11.182697014 -0700 +@@ -1,5 +1,5 @@ + /* { dg-do run } */ +-/* { dg-options "-Os -march=armv7-a" } */ ++/* { dg-options "-Os" } */ + #include <stdint.h> + #include <stdlib.h> + +Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr44788.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/pr44788.c 2011-06-24 08:13:47.000000000 -0700 ++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr44788.c 2011-10-17 17:46:11.182697014 -0700 +@@ -1,6 +1,6 @@ + /* { dg-do compile } */ + /* { dg-require-effective-target arm_thumb2_ok } */ +-/* { dg-options "-Os -fno-strict-aliasing -fPIC -mthumb -march=armv7-a -mfpu=vfp3 -mfloat-abi=softfp" } */ ++/* { dg-options "-Os -fno-strict-aliasing -fPIC -mthumb -mfpu=vfp3 -mfloat-abi=softfp" } */ + + void joint_decode(float* mlt_buffer1, int t) { + int i; +Index: gcc-4_6-branch/gcc/testsuite/gcc.target/arm/sync-1.c +=================================================================== +--- gcc-4_6-branch.orig/gcc/testsuite/gcc.target/arm/sync-1.c 2011-06-24 08:13:47.000000000 -0700 ++++ gcc-4_6-branch/gcc/testsuite/gcc.target/arm/sync-1.c 2011-10-17 17:46:11.182697014 -0700 +@@ -1,5 +1,6 @@ +-/* { dg-do run } */ +-/* { dg-options "-O2 -march=armv7-a" } */ ++ ++/* { dg-do run { target sync_int_long } } */ ++/* { dg-options "-O2" } */ + + volatile int mem; + diff --git a/meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch b/meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch new file mode 100644 index 0000000000..5271ffa6f2 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch @@ -0,0 +1,63 @@ +2011-02-02 Richard Sandiford <richard.sandiford@linaro.org> + + gcc/ + PR target/47551 + * config/arm/arm.c (coproc_secondary_reload_class): Handle + structure modes. Don't check neon_vector_mem_operand for + vector or structure modes. + + gcc/testsuite/ + PR target/47551 + * gcc.target/arm/neon-modes-2.c: New test. + +=== modified file 'gcc/config/arm/arm.c' +--- old/gcc/config/arm/arm.c 2011-02-21 14:04:51 +0000 ++++ new/gcc/config/arm/arm.c 2011-03-02 11:38:43 +0000 +@@ -9139,11 +9139,14 @@ + return GENERAL_REGS; + } + ++ /* The neon move patterns handle all legitimate vector and struct ++ addresses. */ + if (TARGET_NEON ++ && MEM_P (x) + && (GET_MODE_CLASS (mode) == MODE_VECTOR_INT +- || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT) +- && neon_vector_mem_operand (x, 0)) +- return NO_REGS; ++ || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT ++ || VALID_NEON_STRUCT_MODE (mode))) ++ return NO_REGS; + + if (arm_coproc_mem_operand (x, wb) || s_register_operand (x, mode)) + return NO_REGS; + +=== added file 'gcc/testsuite/gcc.target/arm/neon-modes-2.c' +--- old/gcc/testsuite/gcc.target/arm/neon-modes-2.c 1970-01-01 00:00:00 +0000 ++++ new/gcc/testsuite/gcc.target/arm/neon-modes-2.c 2011-02-02 10:02:45 +0000 +@@ -0,0 +1,24 @@ ++/* { dg-do compile } */ ++/* { dg-require-effective-target arm_neon_ok } */ ++/* { dg-options "-O1" } */ ++/* { dg-add-options arm_neon } */ ++ ++#include "arm_neon.h" ++ ++#define SETUP(A) x##A = vld3_u32 (ptr + A * 0x20) ++#define MODIFY(A) x##A = vld3_lane_u32 (ptr + A * 0x20 + 0x10, x##A, 1) ++#define STORE(A) vst3_u32 (ptr + A * 0x20, x##A) ++ ++#define MANY(A) A (0), A (1), A (2), A (3), A (4), A (5) ++ ++void ++bar (uint32_t *ptr, int y) ++{ ++ uint32x2x3_t MANY (SETUP); ++ int *x = __builtin_alloca (y); ++ int z[0x1000]; ++ foo (x, z); ++ MANY (MODIFY); ++ foo (x, z); ++ MANY (STORE); ++} + diff --git a/meta/recipes-devtools/gcc/gcc-configure-sdk.inc b/meta/recipes-devtools/gcc/gcc-configure-sdk.inc index de80870310..f130b4757b 100644 --- a/meta/recipes-devtools/gcc/gcc-configure-sdk.inc +++ b/meta/recipes-devtools/gcc/gcc-configure-sdk.inc @@ -4,10 +4,10 @@ require gcc-configure-common.inc USE_NLS = '${@base_conditional( "TARGET_OS", "linux-uclibc", "no", "", d )}' USE_NLS = '${@base_conditional( "TARGET_OS", "linux-uclibceabi", "no", "", d )}' -EXTRA_OECONF_PATHS = "--with-local-prefix=${SDKPATH}/sysroots/${TARGET_SYS}${target_exec_prefix} \ +EXTRA_OECONF_PATHS = "--with-local-prefix=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}${target_exec_prefix} \ --with-gxx-include-dir=${target_includedir}/c++ \ --with-build-time-tools=${STAGING_DIR_NATIVE}${prefix_native}/${TARGET_SYS}/bin \ - --with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS} \ + --with-sysroot=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS} \ --with-build-sysroot=${STAGING_DIR_TARGET}" # diff --git a/meta/recipes-devtools/gcc/gcc-cross4.inc b/meta/recipes-devtools/gcc/gcc-cross4.inc index ea20a24a01..4a20818d2f 100644 --- a/meta/recipes-devtools/gcc/gcc-cross4.inc +++ b/meta/recipes-devtools/gcc/gcc-cross4.inc @@ -1 +1,3 @@ require gcc-cross.inc + +EXTRA_OECONF_append_sh4 = " --with-multilib-list= --enable-incomplete-targets " diff --git a/meta/recipes-devtools/gcc/gcc-crosssdk-intermediate.inc b/meta/recipes-devtools/gcc/gcc-crosssdk-intermediate.inc index ed5d5e838d..8f20d20156 100644 --- a/meta/recipes-devtools/gcc/gcc-crosssdk-intermediate.inc +++ b/meta/recipes-devtools/gcc/gcc-crosssdk-intermediate.inc @@ -7,3 +7,5 @@ SYSTEMLIBS1 = "${SDKPATHNATIVE}${libdir_nativesdk}/" DEPENDS = "virtual/${TARGET_PREFIX}binutils-crosssdk gettext-native" DEPENDS += "virtual/${TARGET_PREFIX}libc-initial-nativesdk" PROVIDES = "virtual/${TARGET_PREFIX}gcc-intermediate-crosssdk" + +EXTRA_OECONF += " --with-headers=${STAGING_DIR_TCBOOTSTRAP}${SYSTEMHEADERS} " diff --git a/meta/recipes-devtools/gcc/gcc-package-sdk.inc b/meta/recipes-devtools/gcc/gcc-package-sdk.inc index 7db7c52eff..e2095e39fd 100644 --- a/meta/recipes-devtools/gcc/gcc-package-sdk.inc +++ b/meta/recipes-devtools/gcc/gcc-package-sdk.inc @@ -13,11 +13,14 @@ FILES_${PN} = "\ ${gcclibdir}/${TARGET_SYS}/${BINV}/lib* \ ${gcclibdir}/${TARGET_SYS}/${BINV}/include \ ${gcclibdir}/${TARGET_SYS}/${BINV}/include-fixed \ + ${gcclibdir}/${TARGET_SYS}/${BINV}/plugin/include/ \ ${includedir}/c++/${BINV} \ ${prefix}/${TARGET_SYS}/bin/* \ ${prefix}/${TARGET_SYS}/lib/* \ ${prefix}/${TARGET_SYS}/usr/include/* \ " +INSANE_SKIP_${PN} += "dev-so" + FILES_${PN}-doc = "\ ${infodir} \ ${mandir} \ @@ -39,6 +42,8 @@ do_install () { # We use libiberty from binutils rm -f ${D}${prefix}/${TARGET_SYS}/lib/libiberty.a + # Not sure where the strange paths come from + rm -f ${D}${libdir}/../lib/libiberty.a rm -f ${D}${libdir}/libiberty.a # Insert symlinks into libexec so when tools without a prefix are searched for, the correct ones are diff --git a/meta/recipes-devtools/gcc/gcc-package-target.inc b/meta/recipes-devtools/gcc/gcc-package-target.inc index a0e5da4603..f0f1a046ff 100644 --- a/meta/recipes-devtools/gcc/gcc-package-target.inc +++ b/meta/recipes-devtools/gcc/gcc-package-target.inc @@ -24,6 +24,8 @@ FILES_${PN} = "\ ${gcclibdir}/${TARGET_SYS}/${BINV}/include \ ${gcclibdir}/${TARGET_SYS}/${BINV}/include-fixed \ " +INSANE_SKIP_${PN} += "dev-so" + FILES_${PN}-dbg += "\ ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/.debug/ \ " diff --git a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb index 09e3c1ed42..500dda9054 100644 --- a/meta/recipes-devtools/gcc/libgcc_4.5.1.bb +++ b/meta/recipes-devtools/gcc/libgcc_4.5.1.bb @@ -12,6 +12,7 @@ FILES_${PN} = "${base_libdir}/libgcc*.so.*" FILES_${PN}-dev = " \ ${base_libdir}/libgcc*.so \ ${libdir}/${TARGET_SYS}/${BINV}/crt* \ + ${libdir}/${TARGET_SYS}/${BINV}/libgcov.a \ ${libdir}/${TARGET_SYS}/${BINV}/libgcc*" do_configure[noexec] = "1" diff --git a/meta/recipes-devtools/gcc/libgcc_4.6.bb b/meta/recipes-devtools/gcc/libgcc_4.6.bb index 63a46ecb08..6ba03393c5 100644 --- a/meta/recipes-devtools/gcc/libgcc_4.6.bb +++ b/meta/recipes-devtools/gcc/libgcc_4.6.bb @@ -12,6 +12,7 @@ FILES_${PN} = "${base_libdir}/libgcc*.so.*" FILES_${PN}-dev = " \ ${base_libdir}/libgcc*.so \ ${libdir}/${TARGET_SYS}/${BINV}/crt* \ + ${libdir}/${TARGET_SYS}/${BINV}/libgcov.a \ ${libdir}/${TARGET_SYS}/${BINV}/libgcc*" do_configure[noexec] = "1" diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc index 90a20e2868..ec0748e527 100644 --- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc +++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc @@ -4,4 +4,4 @@ DESCRIPTION = "cross-canadian gdb for ${TARGET_ARCH} target - GNU debugger" PN = "gdb-cross-canadian-${TRANSLATED_TARGET_ARCH}" BPN = "gdb" -DEPENDS = "ncurses-nativesdk expat-nativesdk gettext-nativesdk" +DEPENDS = "ncurses-nativesdk expat-nativesdk gettext-nativesdk readline-nativesdk" diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian_7.3a.bb b/meta/recipes-devtools/gdb/gdb-cross-canadian_7.3a.bb index 7e8ad04310..555bef1bb5 100644 --- a/meta/recipes-devtools/gdb/gdb-cross-canadian_7.3a.bb +++ b/meta/recipes-devtools/gdb/gdb-cross-canadian_7.3a.bb @@ -1,7 +1,7 @@ require gdb-common.inc require gdb-cross-canadian.inc -PR = "${INC_PR}.0" +PR = "${INC_PR}.1" GDBPROPREFIX = "--program-prefix='${TARGET_PREFIX}'" EXPAT = "--with-expat" diff --git a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb index de07f434b8..e812ebf0a8 100644 --- a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb +++ b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb @@ -10,7 +10,7 @@ INHIBIT_DEFAULT_DEPS = "1" FIXEDSRCDATE = "${@bb.data.getVar('FILE', d, 1).split('_')[-1].split('.')[0]}" PV = "0.1+cvs${FIXEDSRCDATE}" -PR = "r4" +PR = "r5" SRC_URI = "cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=${FIXEDSRCDATE} \ file://config-guess-uclibc.patch \ @@ -28,7 +28,7 @@ do_install () { sed -e 's,@gnu-configdir@,${datadir}/gnu-config,g' \ -e 's,@autom4te_perllibdir@,${datadir}/autoconf,g' > ${D}${bindir}/gnu-configize # In the native case we want the system perl as perl-native can't have built yet - if [ "${BUILD_ARCH}" != "${TARGET_ARCH}" ]; then + if [ "${PN}" != "gnu-config-native" -a "${PN}" != "gnu-config-nativesdk" ]; then sed -i -e 's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi chmod 755 ${D}${bindir}/gnu-configize @@ -38,4 +38,4 @@ do_install () { PACKAGES = "${PN}" FILES_${PN} = "${bindir} ${datadir}/gnu-config" -BBCLASSEXTEND = "native" +BBCLASSEXTEND = "native nativesdk" diff --git a/meta/recipes-devtools/icecc-create-env/icecc-create-env-native/icecc-create-env b/meta/recipes-devtools/icecc-create-env/icecc-create-env-native/icecc-create-env new file mode 100755 index 0000000000..7e4dbc414e --- /dev/null +++ b/meta/recipes-devtools/icecc-create-env/icecc-create-env-native/icecc-create-env @@ -0,0 +1,192 @@ +#! /usr/bin/env bash +# icecc -- A simple distributed compiler system +# +# Copyright (C) 2004 by the Icecream Authors +# GPL + +target_files= + +is_contained () +{ + case " $target_files " in + *" $1 "* ) return 0 ;; + *"=$1 "* ) return 0;; + * ) return 1 ;; + esac +} + +add_file () +{ + local name="$1" + local path="$1"; + if test -n "$2"; then + name="$2" + fi + test -z "$name" && return + # ls -H isn't really the same as readlink, but + # readlink is not portable enough. + path=`ls -H $path` + toadd="$name=$path" + is_contained "$toadd" && return + if test -z "$silent"; then + echo "adding file $toadd" + fi + target_files="$target_files $toadd" + if test -x "$path"; then + # Only call ldd when it makes sense + if file -L "$path" | grep 'ELF' > /dev/null 2>&1; then + if ! file -L "$path" | grep 'static' > /dev/null 2>&1; then + # ldd now outputs ld as /lib/ld-linux.so.xx on current nptl based glibc + # this regexp parse the outputs like: + # ldd /usr/bin/gcc + # linux-gate.so.1 => (0xffffe000) + # libc.so.6 => /lib/tls/libc.so.6 (0xb7e81000) + # /lib/ld-linux.so.2 (0xb7fe8000) + # covering both situations ( with => and without ) + for lib in `ldd "$path" | sed -n 's,^[^/]*\(/[^ ]*\).*,\1,p'`; do + test -f "$lib" || continue + # Check wether the same library also exists in the parent directory, + # and prefer that on the assumption that it is a more generic one. + local baselib=`echo "$lib" | sed 's,\(/[^/]*\)/.*\(/[^/]*\)$,\1\2,'` + test -f "$baselib" && lib=$baselib + add_file "$lib" + done + fi + fi + fi +} + +# backward compat +if test "$1" = "--respect-path"; then + shift +fi + +#add a --silent switch to avoid "broken pipe" errors when calling this scipt from within OE +if test "$1" = "--silent"; then + silent=1 + shift +fi + + +added_gcc=$1 +shift +added_gxx=$1 +shift +added_as=$1 +shift +archive_name=$1 + +if test -z "$added_gcc" || test -z "$added_gxx" ; then + echo "usage: $0 <gcc_path> <g++_path>" + exit 1 +fi + +if ! test -x "$added_gcc" ; then + echo "'$added_gcc' is no executable." + exit 1 +fi + +if ! test -x "$added_gxx" ; then + echo "'$added_gcc' is no executable." + exit 1 +fi + + + +add_file $added_gcc /usr/bin/gcc +add_file $added_gxx /usr/bin/g++ + +if test -z "$added_as" ; then + add_file /usr/bin/as /usr/bin/as +else + if ! test -x "$added_as" ; then + echo "'$added_as' is no executable." + exit 1 + fi + + add_file $added_as /usr/bin/as +fi + +add_file `$added_gcc -print-prog-name=cc1` /usr/bin/cc1 +add_file `$added_gxx -print-prog-name=cc1plus` /usr/bin/cc1plus +specfile=`$added_gcc -print-file-name=specs` +if test -n "$specfile" && test -e "$specfile"; then + add_file "$specfile" +fi + +ltofile=`$added_gcc -print-prog-name=lto1` +pluginfile="${ltofile%lto1}liblto_plugin.so" +if test -r "$pluginfile" +then + add_file $pluginfile ${pluginfile#*usr} + add_file $pluginfile /usr${pluginfile#*usr} +fi + +tempdir=`mktemp -d /tmp/iceccenvXXXXXX` +new_target_files= +for i in $target_files; do + case $i in + *=/*) + target=`echo $i | cut -d= -f1` + path=`echo $i | cut -d= -f2` + ;; + *) + path=$i + target=$i + ;; + esac + mkdir -p $tempdir/`dirname $target` + cp -p $path $tempdir/$target + if test -f $tempdir/$target -a -x $tempdir/$target; then + strip -s $tempdir/$target 2>/dev/null + fi + target=`echo $target | cut -b2-` + new_target_files="$new_target_files $target" +done + +#sort the files +target_files=`for i in $new_target_files; do echo $i; done | sort` + +#test if an archive name was supplied +#if not use the md5 of all files as the archive name +if test -z "$archive_name"; then + md5sum=NONE + for file in /usr/bin/md5sum /bin/md5 /usr/bin/md5; do + if test -x $file; then + md5sum=$file + break + fi + done + + #calculate md5 and use it as the archive name + archive_name=`for i in $target_files; do test -f $tempdir/$i && $md5sum $tempdir/$i; done | sed -e 's/ .*$//' | $md5sum | sed -e 's/ .*$//'`.tar.gz || { + if test -z "$silent"; then + echo "Couldn't compute MD5 sum." + fi + exit 2 + } + mydir=`pwd` +else + mydir="`dirname "$archive_name"`" + + #check if we have a full path or only a filename + if test "$mydir" = "." ; then + mydir=`pwd` + else + mydir="" + fi +fi + +if test -z "$silent"; then +echo "creating $archive_name" +fi + +cd $tempdir +tar -czhf "$mydir/$archive_name" $target_files || { + if test -z "$silent"; then + echo "Couldn't create archive" + fi + exit 3 +} +cd .. +rm -rf $tempdir diff --git a/meta/recipes-devtools/icecc-create-env/icecc-create-env-native/icecc-lto-update.patch b/meta/recipes-devtools/icecc-create-env/icecc-create-env-native/icecc-lto-update.patch deleted file mode 100644 index a7af2e3a98..0000000000 --- a/meta/recipes-devtools/icecc-create-env/icecc-create-env-native/icecc-lto-update.patch +++ /dev/null @@ -1,103 +0,0 @@ ---- a/icecc-create-env 2006-12-14 09:50:46.000000000 +0300 -+++ b/icecc-create-env 2011-08-31 17:52:45.000000000 +0400 -@@ -27,9 +27,6 @@ - # readlink is not portable enough. - path=`ls -H $path` - toadd="$name=$path" -- if test "$name" = "$path"; then -- toadd=$path -- fi - is_contained "$toadd" && return - if test -z "$silent"; then - echo "adding file $toadd" -@@ -117,6 +114,14 @@ - add_file "$specfile" - fi - -+ltofile=`$added_gcc -print-prog-name=lto1` -+pluginfile="${ltofile%lto1}liblto_plugin.so" -+if test -r "$pluginfile" -+then -+ add_file $pluginfile ${pluginfile#*usr} -+ add_file $pluginfile /usr${pluginfile#*usr} -+fi -+ - tempdir=`mktemp -d /tmp/iceccenvXXXXXX` - new_target_files= - for i in $target_files; do -@@ -140,49 +147,44 @@ - done - - #sort the files -- target_files=`for i in $new_target_files; do echo $i; done | sort` -+target_files=`for i in $new_target_files; do echo $i; done | sort` - - #test if an archive name was supplied - #if not use the md5 of all files as the archive name - if test -z "$archive_name"; then --md5sum=NONE --for file in /usr/bin/md5sum /bin/md5 /usr/bin/md5; do -- if test -x $file; then -- md5sum=$file -- break -- fi --done -+ md5sum=NONE -+ for file in /usr/bin/md5sum /bin/md5 /usr/bin/md5; do -+ if test -x $file; then -+ md5sum=$file -+ break -+ fi -+ done - --#calculate md5 and use it as the archive name --archive_name=`for i in $target_files; do $md5sum $tempdir/$i; done | sed -e 's/ .*$//' | $md5sum | sed -e 's/ .*$//'` || { -- if test -z "$silent"; then -- echo "Couldn't compute MD5 sum." -+ #calculate md5 and use it as the archive name -+ archive_name=`for i in $target_files; do test -f $tempdir/$i && $md5sum $tempdir/$i; done | sed -e 's/ .*$//' | $md5sum | sed -e 's/ .*$//'`.tar.gz || { -+ if test -z "$silent"; then -+ echo "Couldn't compute MD5 sum." -+ fi -+ exit 2 -+ } -+ mydir=`pwd` -+else -+ mydir="`dirname "$archive_name"`" -+ -+ #check if we have a full path or only a filename -+ if test "$mydir" = "." ; then -+ mydir=`pwd` -+ else -+ mydir="" - fi -- exit 2 --} -- - fi - - if test -z "$silent"; then --echo "creating $archive_name.tar.gz" -+echo "creating $archive_name" - fi - --if test -z "$archive_name"; then -- mydir=`pwd` --else --# mydir=dirname ${archive_name} -- mydir=${archive_name%/*} -- --#check if we have a full path or only a filename -- if test -z "$mydir"; then -- mydir=`pwd` -- else -- mydir="" -- fi -- --fi - cd $tempdir --tar -czhf "$mydir/$archive_name".tar.gz $target_files || { -+tar -czhf "$mydir/$archive_name" $target_files || { - if test -z "$silent"; then - echo "Couldn't create archive" - fi diff --git a/meta/recipes-devtools/icecc-create-env/icecc-create-env-native_0.1.bb b/meta/recipes-devtools/icecc-create-env/icecc-create-env-native_0.1.bb index 9a440baccf..621384387b 100644 --- a/meta/recipes-devtools/icecc-create-env/icecc-create-env-native_0.1.bb +++ b/meta/recipes-devtools/icecc-create-env/icecc-create-env-native_0.1.bb @@ -7,7 +7,7 @@ PRIORITY = "optional" LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://icecc-create-env;beginline=2;endline=5;md5=ae1df3d6a058bfda40b66094c5f6065f" -PR = "r1" +PR = "r2" DEPENDS = "" INHIBIT_DEFAULT_DEPS = "1" @@ -15,8 +15,7 @@ INHIBIT_DEFAULT_DEPS = "1" inherit native PATCHTOOL = "patch" -SRC_URI = "http://www.digital-opsis.com/openembedded/icecc-create-env-${PV}.tar.gz \ - file://icecc-lto-update.patch " +SRC_URI = "file://icecc-create-env" S = "${WORKDIR}" @@ -24,6 +23,3 @@ do_install() { install -d ${D}/${bindir} install -m 0755 ${WORKDIR}/icecc-create-env ${D}/${bindir} } - -SRC_URI[md5sum] = "641ec45fe377529c7fd914f77b11b44f" -SRC_URI[sha256sum] = "9ff8360375432a7a5c476cc6d55b3fdea9d6f3edc080d295a60421d8f47b1834" diff --git a/meta/recipes-devtools/icon-naming-utils/icon-naming-utils-native_0.8.7.bb b/meta/recipes-devtools/icon-naming-utils/icon-naming-utils-native_0.8.7.bb index 4760c9627e..afcb6a7358 100644 --- a/meta/recipes-devtools/icon-naming-utils/icon-naming-utils-native_0.8.7.bb +++ b/meta/recipes-devtools/icon-naming-utils/icon-naming-utils-native_0.8.7.bb @@ -5,6 +5,8 @@ PR = "r3" LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" SRC_URI = "http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz" +SRC_URI[md5sum] = "4abe604721ce2ccb67f451aa7ceb44d6" +SRC_URI[sha256sum] = "1cb49ce6a04626939893a447da696f20003903d61bd80c6d74d29dd79ca340d2" S = "${WORKDIR}/icon-naming-utils-${PV}" diff --git a/meta/recipes-devtools/installer/adt-installer/adt_installer.conf b/meta/recipes-devtools/installer/adt-installer/adt_installer.conf index 2038b09e9c..275756e187 100644 --- a/meta/recipes-devtools/installer/adt-installer/adt_installer.conf +++ b/meta/recipes-devtools/installer/adt-installer/adt_installer.conf @@ -23,7 +23,7 @@ # Your yocto distro repository, this should include IPKG based packages and root filesystem files where the installation is based on -YOCTOADT_REPO="http://adtrepo.yoctoproject.org/$YOCTOADT_VERSION" +YOCTOADT_REPO="http://adtrepo.yoctoproject.org/YOCTOADT_VERSION" # The following are for system wide setup # Target architectures that you want to setup host cross dev environment for diff --git a/meta/recipes-devtools/installer/adt-installer/scripts/adt_installer_internal b/meta/recipes-devtools/installer/adt-installer/scripts/adt_installer_internal index 870931e37b..6201095117 100755 --- a/meta/recipes-devtools/installer/adt-installer/scripts/adt_installer_internal +++ b/meta/recipes-devtools/installer/adt-installer/scripts/adt_installer_internal @@ -91,18 +91,12 @@ check_result OPKG_INSTALL_CMD="$OPKG_CMD " OPKG_INSTALL_NATIVE_CMD="$OPKG_INSTALL_CMD -f $OPKG_CONFIG_FILE -o $NATIVE_INSTALL_DIR install" -echo_info "Installing pseudo nativesdk ...\n" -$OPKG_INSTALL_NATIVE_CMD pseudo-nativesdk &>> $YOCTOADT_INSTALL_LOG_FILE -check_result -echo_info "Installing opkg nativesdk ...\n" -$OPKG_INSTALL_NATIVE_CMD opkg-nativesdk &>> $YOCTOADT_INSTALL_LOG_FILE -check_result -echo_info "Installing pkgconfig nativesdk ...\n" -$OPKG_INSTALL_NATIVE_CMD pkgconfig-nativesdk &>> $YOCTOADT_INSTALL_LOG_FILE -check_result -echo_info "Installing libtool nativesdk ...\n" -$OPKG_INSTALL_NATIVE_CMD libtool-nativesdk &>> $YOCTOADT_INSTALL_LOG_FILE -check_result +BASE_HOSTSDK_PKGNAMES="pseudo opkg pkgconfig libtool autoconf automake" +for pkg in $BASE_HOSTSDK_PKGNAMES; do + echo_info "Installing ${pkg} nativesdk ...\n" + $OPKG_INSTALL_NATIVE_CMD ${pkg}-nativesdk &>> $YOCTOADT_INSTALL_LOG_FILE + check_result +done for native_target_type in $YOCTOADT_TARGETS; do native_target_type=`echo "$native_target_type" | sed -e 's/x86_64/x86-64/' -e 's/ppc/powerpc/' -e 's/x86$/i586/'` diff --git a/meta/recipes-devtools/installer/adt-installer_1.0.bb b/meta/recipes-devtools/installer/adt-installer_1.0.bb index 74e1b9f2ba..5e76067206 100644 --- a/meta/recipes-devtools/installer/adt-installer_1.0.bb +++ b/meta/recipes-devtools/installer/adt-installer_1.0.bb @@ -29,17 +29,14 @@ LICENSE = "MIT" ALLOW_EMPTY = "1" PACKAGES = "" -PACKAGE_ARCH = "all" -PR = "r4" +PR = "r6" ADT_DEPLOY = "${TMPDIR}/deploy/sdk/" ADT_DIR = "${WORKDIR}/adt-installer/" YOCTOADT_VERSION = "${SDK_VERSION}" S = "${WORKDIR}/trunk" -inherit deploy - SRCREV = "596" PV = "0.1.8+svnr${SRCPV}" SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;proto=http \ @@ -56,9 +53,9 @@ SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;proto=http \ ADTREPO = "http://adtrepo.yoctoproject.org/${SDK_VERSION}" -do_deploy[umask] = 022 +do_populate_adt[umask] = 022 -fakeroot do_deploy () { +fakeroot do_populate_adt () { cd ${WORKDIR} mkdir -p ${ADT_DEPLOY} rm -f ${ADT_DEPLOY}/adt-installer.tar.bz2 @@ -74,13 +71,14 @@ fakeroot do_deploy () { echo 'YOCTOADT_VERSION=${SDK_VERSION}' > ${ADT_DIR}/temp.conf cat ${ADT_DIR}/adt_installer.conf >> ${ADT_DIR}/temp.conf mv ${ADT_DIR}/temp.conf ${ADT_DIR}/adt_installer.conf + sed -i -e 's#YOCTOADT_VERSION#${SDK_VERSION}#' ${ADT_DIR}/adt_installer.conf echo 'SDK_VENDOR=${SDK_VENDOR}' >> ${ADT_DIR}/scripts/data_define echo 'INSTALL_FOLDER=${SDKPATH}' >> ${ADT_DIR}/scripts/data_define tar cfj adt_installer.tar.bz2 adt-installer cp ${WORKDIR}/adt_installer.tar.bz2 ${ADT_DEPLOY} } -do_install[noexec] = "1" +do_populate_adt[nostamp] = "1" do_configure[noexec] = "1" do_compile[noexec] = "1" do_package[noexec] = "1" @@ -90,4 +88,4 @@ do_package_write_rpm[noexec] = "1" do_package_write_deb[noexec] = "1" do_poplulate_sysroot[noexec] = "1" -addtask deploy before do_populate_sysroot after do_patch +addtask populate_adt before do_build after do_install diff --git a/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch b/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch new file mode 100644 index 0000000000..476d0913d4 --- /dev/null +++ b/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch @@ -0,0 +1,29 @@ +Index: intltool-0.40.6/intltool.m4 +=================================================================== +--- intltool-0.40.6.orig/intltool.m4 2009-02-14 14:12:28.000000000 -0800 ++++ intltool-0.40.6/intltool.m4 2011-11-23 15:39:34.689561872 -0800 +@@ -122,14 +122,16 @@ + IT_PERL_VERSION="`$INTLTOOL_PERL -e \"printf '%vd', $^V\"`" + AC_MSG_RESULT([$IT_PERL_VERSION]) + fi +-if test "x$2" != "xno-xml"; then +- AC_MSG_CHECKING([for XML::Parser]) +- if `$INTLTOOL_PERL -e "require XML::Parser" 2>/dev/null`; then +- AC_MSG_RESULT([ok]) +- else +- AC_MSG_ERROR([XML::Parser perl module is required for intltool]) +- fi +-fi ++ ++# Disable this check since we know XML::Parser is installed ++#if test "x$2" != "xno-xml"; then ++# AC_MSG_CHECKING([for XML::Parser]) ++# if `$INTLTOOL_PERL -e "require XML::Parser" 2>/dev/null`; then ++# AC_MSG_RESULT([ok]) ++# else ++# AC_MSG_ERROR([XML::Parser perl module is required for intltool]) ++# fi ++#fi + + # Substitute ALL_LINGUAS so we can use it in po/Makefile + AC_SUBST(ALL_LINGUAS) diff --git a/meta/recipes-devtools/intltool/intltool_0.40.6.bb b/meta/recipes-devtools/intltool/intltool_0.40.6.bb index e9871fc098..c820f11bf4 100644 --- a/meta/recipes-devtools/intltool/intltool_0.40.6.bb +++ b/meta/recipes-devtools/intltool/intltool_0.40.6.bb @@ -1,14 +1,19 @@ require intltool.inc LICENSE="GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" -PR = "r5" +PR = "r6" SRC_URI_append = " file://intltool-nowarn-0.40.0.patch \ ${NATIVEPATCHES} \ " -NATIVEPATCHES = "file://noperlcheck.patch" -NATIVEPATCHES_virtclass-native = "file://use-nativeperl.patch" +# +# All of the intltool scripts have the correct paths to perl already +# embedded into them and can find perl fine, so we add the remove xml-check +# in the intltool.m4 via the remove-xml-check.patch +NATIVEPATCHES = "file://noperlcheck.patch \ + file://remove-xml-check.patch" +NATIVEPATCHES_virtclass-native = "file://use-nativeperl.patch" SRC_URI[md5sum] = "69bc0353323112f42ad4f9cf351bc3e5" SRC_URI[sha256sum] = "4d1e5f8561f09c958e303d4faa885079a5e173a61d28437d0013ff5efc9e3b64" diff --git a/meta/recipes-devtools/m4/m4-native_1.4.16.bb b/meta/recipes-devtools/m4/m4-native_1.4.16.bb index fa871b38ae..6f36e612d8 100644 --- a/meta/recipes-devtools/m4/m4-native_1.4.16.bb +++ b/meta/recipes-devtools/m4/m4-native_1.4.16.bb @@ -10,3 +10,4 @@ do_configure() { oe_runconf } +BBCLASSEXTEND = "" diff --git a/meta/recipes-devtools/m4/m4_1.4.16.bb b/meta/recipes-devtools/m4/m4_1.4.16.bb index b50c022959..58b049179a 100644 --- a/meta/recipes-devtools/m4/m4_1.4.16.bb +++ b/meta/recipes-devtools/m4/m4_1.4.16.bb @@ -6,7 +6,7 @@ LICENSE = "GPLv3" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\ file://examples/COPYING;md5=fbc986d45b3dae6725c29870dd6b669d" -PR = "r0" +PR = "r1" SRC_URI = "${GNU_MIRROR}/m4/m4-${PV}.tar.gz \ file://ac_config_links.patch" @@ -16,3 +16,5 @@ SRC_URI[sha256sum] = "e9176a35bb13a1b08482359aa554ee8072794f58f00e4827bf0e06b570 inherit autotools EXTRA_OEMAKE += "'infodir=${infodir}'" + +BBCLASSEXTEND = "nativesdk" diff --git a/meta/recipes-devtools/m4/m4_1.4.9.bb b/meta/recipes-devtools/m4/m4_1.4.9.bb index 94c8bdec1c..e79239b95a 100644 --- a/meta/recipes-devtools/m4/m4_1.4.9.bb +++ b/meta/recipes-devtools/m4/m4_1.4.9.bb @@ -6,7 +6,7 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe\ file://examples/COPYING;md5=1d49bd61dc590f014cae7173b43e3e5c" -PR = "r0" +PR = "r1" SRC_URI = "${GNU_MIRROR}/m4/m4-${PV}.tar.gz \ file://fix_for_circular_dependency.patch " @@ -16,3 +16,5 @@ SRC_URI[sha256sum] = "815ce53853fbf6493617f467389b799208b1ec98296b95be44a683f8bc inherit autotools EXTRA_OEMAKE += "'infodir=${infodir}'" + +BBCLASSEXTEND = "nativesdk" diff --git a/meta/recipes-devtools/mtools/mtools_3.9.9.bb b/meta/recipes-devtools/mtools/mtools_3.9.9.bb index 2e4c1cba7d..f0428c10e3 100644 --- a/meta/recipes-devtools/mtools/mtools_3.9.9.bb +++ b/meta/recipes-devtools/mtools/mtools_3.9.9.bb @@ -20,4 +20,6 @@ inherit autotools EXTRA_OECONF = "--without-x" +PARALLEL_MAKEINST = "" + BBCLASSEXTEND = "native" diff --git a/meta/recipes-devtools/mtools/mtools_4.0.16.bb b/meta/recipes-devtools/mtools/mtools_4.0.16.bb index f5dca26724..df67854685 100644 --- a/meta/recipes-devtools/mtools/mtools_4.0.16.bb +++ b/meta/recipes-devtools/mtools/mtools_4.0.16.bb @@ -18,4 +18,6 @@ inherit autotools EXTRA_OECONF = "--without-x" +PARALLEL_MAKEINST = "" + BBCLASSEXTEND = "native" diff --git a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb index 6cc6bb5d2b..72f5bb297b 100644 --- a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb +++ b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb @@ -28,6 +28,11 @@ EXTRA_OECONF = "--enable-spincludedir=${STAGING_INCDIR}/OpenSP \ # results in it being specified twice when configure is run. CONFIGUREOPTS := "${@d.getVar('CONFIGUREOPTS', True).replace('--datadir=${datadir}', '--datadir=${STAGING_DATADIR}/sgml/openjade-${PV}')}" +# CONFIGUREOPTS has hard coded paths so we need to ignore it's vardeps +# there are other bits in there too but they are picked up by other variable +# dependencies so it all works out +do_configure[vardepsexclude] += "CONNFIGUREOPTS" + CFLAGS =+ "-I${S}/include" SSTATEPOSTINSTFUNCS += "openjade_sstate_postinst" diff --git a/meta/recipes-devtools/opkg/opkg/add_uname_support.patch b/meta/recipes-devtools/opkg/opkg/add_uname_support.patch new file mode 100644 index 0000000000..0f627f1178 --- /dev/null +++ b/meta/recipes-devtools/opkg/opkg/add_uname_support.patch @@ -0,0 +1,88 @@ + +When updating packages on the target device we ideally want to match +user and group numbers from the existing file system. This patch encourages +opkg to lookup the uname/gname fields first and only use the hardcoded +numerical values if that fails. + +Upstream-Status: Pending + +RP 11/11/11 + +Index: trunk/libbb/unarchive.c +=================================================================== +--- trunk.orig/libbb/unarchive.c 2011-11-11 15:52:59.761674091 +0000 ++++ trunk/libbb/unarchive.c 2011-11-11 17:04:56.501574419 +0000 +@@ -22,10 +22,13 @@ + #include <stdio.h> + #include <errno.h> + #include <stdlib.h> ++#include <stdbool.h> + #include <string.h> + #include <unistd.h> + #include <utime.h> + #include <libgen.h> ++#include <grp.h> ++#include <pwd.h> + + #include "libbb.h" + +@@ -436,6 +439,42 @@ + free(ar_entry); + } + ++static char uname_cache[32] = ""; ++static uid_t uid_cache; ++ ++static bool update_unamecache(char *uname) { ++ struct passwd *passwd; ++ if (!uname) ++ return FALSE; ++ if (!uname_cache[0] && strcmp(uname_cache, uname) == 0) ++ return TRUE; ++ passwd = getpwnam(uname); ++ if (passwd) { ++ uid_cache = passwd->pw_uid; ++ strncpy(uname, uname_cache, 32); ++ return TRUE; ++ } ++ return FALSE; ++} ++ ++static char gname_cache[32] = ""; ++static gid_t gid_cache; ++ ++static bool update_gnamecache(char *gname) { ++ struct group *group; ++ if (!gname) ++ return FALSE; ++ if (!gname_cache[0] && strcmp(gname_cache, gname) == 0) ++ return TRUE; ++ group = getgrnam(gname); ++ if (group) { ++ gid_cache = group->gr_gid; ++ strncpy(gname, gname_cache, 32); ++ return TRUE; ++ } ++ return FALSE; ++} ++ + + static file_header_t * + get_header_tar(FILE *tar_stream) +@@ -515,8 +554,14 @@ + */ + tar_entry->mode = 07777 & strtol(tar.formated.mode, NULL, 8); + +- tar_entry->uid = strtol(tar.formated.uid, NULL, 8); +- tar_entry->gid = strtol(tar.formated.gid, NULL, 8); ++ if (update_unamecache(tar.formated.uname)) ++ tar_entry->uid = uid_cache; ++ else ++ tar_entry->uid = strtol(tar.formated.uid, NULL, 8); ++ if (update_gnamecache(tar.formated.gname)) ++ tar_entry->gid = gid_cache; ++ else ++ tar_entry->gid = strtol(tar.formated.gid, NULL, 8); + tar_entry->size = strtol(tar.formated.size, NULL, 8); + tar_entry->mtime = strtol(tar.formated.mtime, NULL, 8); + diff --git a/meta/recipes-devtools/opkg/opkg/fix_installorder.patch b/meta/recipes-devtools/opkg/opkg/fix_installorder.patch new file mode 100644 index 0000000000..5e6c40d649 --- /dev/null +++ b/meta/recipes-devtools/opkg/opkg/fix_installorder.patch @@ -0,0 +1,174 @@ +There is a problem with dependency order when installing packages. The key +problem revolves around the satisfy_dependencies_for() function which is +called from opkg_install_pkg just before the installation (and preinst) +happens. + +The satisfy_dependencies_for() function calls pkg_hash_fetch_unsatisfied_dependencies() +which will only return packages which were previously not marked as +*going* to be installed at some point. For the purposes of +opkg_install_pkg() we really need to know which dependencies haven't been +installed yet. + +This patch adds pkg_hash_fetch_satisfied_dependencies() which returns a +list of package dependencies. We can then directly check the status of +these and ensure any hard dependencies (not suggestions or recommendations) +are installed before returning. + +Consider the situation (where -> means 'depends on'): + +X -> A,E +A -> B,E +E -> B +B -> C + +Currently X would install A and E. When installing A the packages B, E +and C would be marked as "to install". When the package B is considered +the second time (as a dependency of E rather than A), it would install +straight away even though C was not currently installed, just marked +as needing to be installed. + +The patch changes the behaviour so B can't install until C really is installed. + +This change is required to run the postinst scripts in the correct order. + +Upstream-Status: Pending + +RP 2011/12/15 + +Index: trunk/libopkg/opkg_install.c +=================================================================== +--- trunk.orig/libopkg/opkg_install.c 2011-12-15 15:58:39.000000000 +0000 ++++ trunk/libopkg/opkg_install.c 2011-12-15 15:58:41.838334788 +0000 +@@ -76,6 +77,27 @@ + } + + if (ndepends <= 0) { ++ pkg_vec_free(depends); ++ depends = pkg_hash_fetch_satisfied_dependencies(pkg); ++ ++ for (i = 0; i < depends->len; i++) { ++ dep = depends->pkgs[i]; ++ /* The package was uninstalled when we started, but another ++ dep earlier in this loop may have depended on it and pulled ++ it in, so check first. */ ++ if ((dep->state_status != SS_INSTALLED) && (dep->state_status != SS_UNPACKED)) { ++ opkg_msg(DEBUG2,"Calling opkg_install_pkg.\n"); ++ err = opkg_install_pkg(dep, 0); ++ /* mark this package as having been automatically installed to ++ * satisfy a dependancy */ ++ dep->auto_installed = 1; ++ if (err) { ++ pkg_vec_free(depends); ++ return err; ++ } ++ } ++ } ++ + pkg_vec_free(depends); + return 0; + } +Index: trunk/libopkg/pkg_depends.c +=================================================================== +--- trunk.orig/libopkg/pkg_depends.c 2010-12-22 16:04:43.000000000 +0000 ++++ trunk/libopkg/pkg_depends.c 2011-12-15 15:58:41.838334788 +0000 +@@ -259,6 +259,88 @@ + return unsatisfied->len; + } + ++ ++pkg_vec_t * ++pkg_hash_fetch_satisfied_dependencies(pkg_t * pkg) ++{ ++ pkg_vec_t *satisfiers; ++ int i, j, k; ++ int count; ++ abstract_pkg_t * ab_pkg; ++ ++ satisfiers = pkg_vec_alloc(); ++ ++ /* ++ * this is a setup to check for redundant/cyclic dependency checks, ++ * which are marked at the abstract_pkg level ++ */ ++ if (!(ab_pkg = pkg->parent)) { ++ opkg_msg(ERROR, "Internal error, with pkg %s.\n", pkg->name); ++ return satisfiers; ++ } ++ ++ count = pkg->pre_depends_count + pkg->depends_count + pkg->recommends_count + pkg->suggests_count; ++ if (!count) ++ return satisfiers; ++ ++ /* foreach dependency */ ++ for (i = 0; i < count; i++) { ++ compound_depend_t * compound_depend = &pkg->depends[i]; ++ depend_t ** possible_satisfiers = compound_depend->possibilities;; ++ ++ if (compound_depend->type == RECOMMEND || compound_depend->type == SUGGEST) ++ continue; ++ ++ if (compound_depend->type == GREEDY_DEPEND) { ++ /* foreach possible satisfier */ ++ for (j = 0; j < compound_depend->possibility_count; j++) { ++ /* foreach provided_by, which includes the abstract_pkg itself */ ++ abstract_pkg_t *abpkg = possible_satisfiers[j]->pkg; ++ abstract_pkg_vec_t *ab_provider_vec = abpkg->provided_by; ++ int nposs = ab_provider_vec->len; ++ abstract_pkg_t **ab_providers = ab_provider_vec->pkgs; ++ int l; ++ for (l = 0; l < nposs; l++) { ++ pkg_vec_t *test_vec = ab_providers[l]->pkgs; ++ /* if no depends on this one, try the first package that Provides this one */ ++ if (!test_vec){ /* no pkg_vec hooked up to the abstract_pkg! (need another feed?) */ ++ continue; ++ } ++ ++ /* cruise this possiblity's pkg_vec looking for an installed version */ ++ for (k = 0; k < test_vec->len; k++) { ++ pkg_t *pkg_scout = test_vec->pkgs[k]; ++ /* not installed, and not already known about? */ ++ if (pkg_scout->state_want == SW_INSTALL && pkg_scout != pkg) ++ pkg_vec_insert(satisfiers, pkg_scout); ++ } ++ } ++ } ++ ++ continue; ++ } ++ ++ /* foreach possible satisfier, look for installed package */ ++ for (j = 0; j < compound_depend->possibility_count; j++) { ++ /* foreach provided_by, which includes the abstract_pkg itself */ ++ depend_t *dependence_to_satisfy = possible_satisfiers[j]; ++ abstract_pkg_t *satisfying_apkg = possible_satisfiers[j]->pkg; ++ pkg_t *satisfying_pkg = ++ pkg_hash_fetch_best_installation_candidate(satisfying_apkg, ++ pkg_installed_and_constraint_satisfied, ++ dependence_to_satisfy, 0); ++ /* Being that I can't test constraing in pkg_hash, I will test it here */ ++ if (satisfying_pkg != NULL && satisfying_pkg != pkg) { ++ if (pkg_constraint_satisfied(satisfying_pkg, dependence_to_satisfy) && satisfying_pkg->state_want == SW_INSTALL) ++ pkg_vec_insert(satisfiers, satisfying_pkg); ++ } ++ ++ } ++ } ++ return satisfiers; ++} ++ ++ + /*checking for conflicts !in replaces + If a packages conflicts with another but is also replacing it, I should not consider it a + really conflicts +Index: trunk/libopkg/pkg_depends.h +=================================================================== +--- trunk.orig/libopkg/pkg_depends.h 2010-12-22 16:04:43.000000000 +0000 ++++ trunk/libopkg/pkg_depends.h 2011-12-15 15:58:41.838334788 +0000 +@@ -82,6 +82,7 @@ + void buildDependedUponBy(pkg_t * pkg, abstract_pkg_t * ab_pkg); + int version_constraints_satisfied(depend_t * depends, pkg_t * pkg); + int pkg_hash_fetch_unsatisfied_dependencies(pkg_t * pkg, pkg_vec_t *depends, char *** unresolved); ++pkg_vec_t * pkg_hash_fetch_satisfied_dependencies(pkg_t * pkg); + pkg_vec_t * pkg_hash_fetch_conflicts(pkg_t * pkg); + int pkg_dependence_satisfiable(depend_t *depend); + int pkg_dependence_satisfied(depend_t *depend); diff --git a/meta/recipes-devtools/opkg/opkg/offline_postinstall.patch b/meta/recipes-devtools/opkg/opkg/offline_postinstall.patch new file mode 100644 index 0000000000..b197f6b731 --- /dev/null +++ b/meta/recipes-devtools/opkg/opkg/offline_postinstall.patch @@ -0,0 +1,57 @@ +When we have an offline root and have specified force-postinstall, +attempt to run the postinstall but if it fails, just leave it in the +status file as neeing to run. We can issue a NOTICE this is happened +but supress errors. This means the OE class doesn't have to do any +further post processing of the postinstalls itself. + +Upstream-Status: Pending + +RP 2011/12/15 + + +Index: trunk/libopkg/pkg.c +=================================================================== +--- trunk.orig/libopkg/pkg.c 2011-12-15 15:58:39.000000000 +0000 ++++ trunk/libopkg/pkg.c 2011-12-15 20:04:50.109992736 +0000 +@@ -1297,8 +1297,9 @@ + free(cmd); + + if (err) { +- opkg_msg(ERROR, "package \"%s\" %s script returned status %d.\n", +- pkg->name, script, err); ++ if (!conf->offline_root) ++ opkg_msg(ERROR, "package \"%s\" %s script returned status %d.\n", ++ pkg->name, script, err); + return err; + } + +Index: trunk/libopkg/opkg_cmd.c +=================================================================== +--- trunk.orig/libopkg/opkg_cmd.c 2011-12-15 19:49:25.826014150 +0000 ++++ trunk/libopkg/opkg_cmd.c 2011-12-15 19:50:52.346012148 +0000 +@@ -453,7 +453,8 @@ + pkg->state_flag &= ~SF_PREFER; + opkg_state_changed++; + } else { +- err = -1; ++ if (!conf->offline_root) ++ err = -1; + } + } + } +Index: trunk/libopkg/opkg_configure.c +=================================================================== +--- trunk.orig/libopkg/opkg_configure.c 2011-12-15 19:50:11.586013081 +0000 ++++ trunk/libopkg/opkg_configure.c 2011-12-15 19:52:15.082010347 +0000 +@@ -35,7 +35,10 @@ + + err = pkg_run_script(pkg, "postinst", "configure"); + if (err) { +- opkg_msg(ERROR, "%s.postinst returned %d.\n", pkg->name, err); ++ if (!conf->offline_root) ++ opkg_msg(ERROR, "%s.postinst returned %d.\n", pkg->name, err); ++ else ++ opkg_msg(NOTICE, "%s.postinst returned %d, marking as unpacked only, configuration required on target.\n", pkg->name, err); + return err; + } + diff --git a/meta/recipes-devtools/opkg/opkg/track_parents.patch b/meta/recipes-devtools/opkg/opkg/track_parents.patch new file mode 100644 index 0000000000..1f54256c2d --- /dev/null +++ b/meta/recipes-devtools/opkg/opkg/track_parents.patch @@ -0,0 +1,99 @@ +Add logic to detect circular dependencies. If we see any dependency from any +given parent twice, ignore it the second time and print a notice message +that we did so. + +Upstream-Status: Pending +RP 2011/12/18 + +Index: trunk/libopkg/opkg_install.c +=================================================================== +--- trunk.orig/libopkg/opkg_install.c 2011-12-18 11:15:17.320725365 +0000 ++++ trunk/libopkg/opkg_install.c 2011-12-18 12:38:54.980609225 +0000 +@@ -84,8 +84,14 @@ + /* The package was uninstalled when we started, but another + dep earlier in this loop may have depended on it and pulled + it in, so check first. */ ++ if (is_pkg_in_pkg_vec(dep->wanted_by, pkg)) { ++ opkg_msg(NOTICE,"Breaking cicular dependency on %s for %s.\n", pkg->name, dep->name); ++ continue; ++ } + if ((dep->state_status != SS_INSTALLED) && (dep->state_status != SS_UNPACKED)) { + opkg_msg(DEBUG2,"Calling opkg_install_pkg.\n"); ++ if (!is_pkg_in_pkg_vec(dep->wanted_by, pkg)) ++ pkg_vec_insert(dep->wanted_by, pkg); + err = opkg_install_pkg(dep, 0); + /* mark this package as having been automatically installed to + * satisfy a dependancy */ +@@ -115,6 +121,8 @@ + /* The package was uninstalled when we started, but another + dep earlier in this loop may have depended on it and pulled + it in, so check first. */ ++ if (!is_pkg_in_pkg_vec(dep->wanted_by, pkg)) ++ pkg_vec_insert(dep->wanted_by, pkg); + if ((dep->state_status != SS_INSTALLED) + && (dep->state_status != SS_UNPACKED)) { + opkg_msg(DEBUG2,"Calling opkg_install_pkg.\n"); +Index: trunk/libopkg/pkg.c +=================================================================== +--- trunk.orig/libopkg/pkg.c 2011-12-18 11:12:39.976729002 +0000 ++++ trunk/libopkg/pkg.c 2011-12-18 11:22:34.528715535 +0000 +@@ -86,6 +86,7 @@ + pkg->section = NULL; + pkg->description = NULL; + pkg->state_want = SW_UNKNOWN; ++ pkg->wanted_by = pkg_vec_alloc(); + pkg->state_flag = SF_OK; + pkg->state_status = SS_NOT_INSTALLED; + pkg->depends_str = NULL; +@@ -191,6 +192,7 @@ + pkg->description = NULL; + + pkg->state_want = SW_UNKNOWN; ++ pkg_vec_free(pkg->wanted_by); + pkg->state_flag = SF_OK; + pkg->state_status = SS_NOT_INSTALLED; + +Index: trunk/libopkg/pkg.h +=================================================================== +--- trunk.orig/libopkg/pkg.h 2011-12-18 11:12:37.120728742 +0000 ++++ trunk/libopkg/pkg.h 2011-12-18 11:15:39.080725150 +0000 +@@ -129,6 +129,7 @@ + char *description; + char *tags; + pkg_state_want_t state_want; ++ pkg_vec_t *wanted_by; + pkg_state_flag_t state_flag; + pkg_state_status_t state_status; + char **depends_str; +Index: trunk/libopkg/pkg_depends.c +=================================================================== +--- trunk.orig/libopkg/pkg_depends.c 2011-12-18 11:14:24.464726569 +0000 ++++ trunk/libopkg/pkg_depends.c 2011-12-18 11:30:32.516704127 +0000 +@@ -30,7 +30,6 @@ + static depend_t * depend_init(void); + static char ** add_unresolved_dep(pkg_t * pkg, char ** the_lost, int ref_ndx); + static char ** merge_unresolved(char ** oldstuff, char ** newstuff); +-static int is_pkg_in_pkg_vec(pkg_vec_t * vec, pkg_t * pkg); + + static int pkg_installed_and_constraint_satisfied(pkg_t *pkg, void *cdata) + { +@@ -531,7 +530,7 @@ + return 0; + } + +-static int is_pkg_in_pkg_vec(pkg_vec_t * vec, pkg_t * pkg) ++int is_pkg_in_pkg_vec(pkg_vec_t * vec, pkg_t * pkg) + { + int i; + pkg_t ** pkgs = vec->pkgs; +Index: trunk/libopkg/pkg_depends.h +=================================================================== +--- trunk.orig/libopkg/pkg_depends.h 2011-12-18 11:28:51.960706484 +0000 ++++ trunk/libopkg/pkg_depends.h 2011-12-18 11:29:19.400705862 +0000 +@@ -87,5 +87,6 @@ + int pkg_dependence_satisfiable(depend_t *depend); + int pkg_dependence_satisfied(depend_t *depend); + const char* constraint_to_str(enum version_constraint c); ++int is_pkg_in_pkg_vec(pkg_vec_t * vec, pkg_t * pkg); + + #endif diff --git a/meta/recipes-devtools/opkg/opkg_svn.bb b/meta/recipes-devtools/opkg/opkg_svn.bb index 099a373f34..f5f540d78e 100644 --- a/meta/recipes-devtools/opkg/opkg_svn.bb +++ b/meta/recipes-devtools/opkg/opkg_svn.bb @@ -11,13 +11,17 @@ RREPLACES_${PN} = "opkg-nogpg" SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;proto=http \ file://add_vercmp.patch \ + file://add_uname_support.patch \ + file://fix_installorder.patch \ + file://offline_postinstall.patch\ + file://track_parents.patch \ " S = "${WORKDIR}/trunk" -SRCREV = "625" +SRCREV = "633" PV = "0.1.8+svnr${SRCPV}" -PR = "r2" +PR = "r5" PACKAGES =+ "libopkg${PKGSUFFIX}-dev libopkg${PKGSUFFIX} update-alternatives-cworth${PKGSUFFIX}" diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig/disable-legacy.patch b/meta/recipes-devtools/pkgconfig/pkgconfig/disable-legacy.patch index 1b3c12a208..30db36c182 100644 --- a/meta/recipes-devtools/pkgconfig/pkgconfig/disable-legacy.patch +++ b/meta/recipes-devtools/pkgconfig/pkgconfig/disable-legacy.patch @@ -7,13 +7,13 @@ pkgconfig with the --disable-legacy-scripts option, to maintain compatibility the default is to leave the scripts enabled. JL - 22/06/10 -Index: pkg-config-0.23/configure.in +Index: pkg-config-0.25/configure.in =================================================================== ---- pkg-config-0.23.orig/configure.in 2008-01-16 22:48:07.000000000 +0000 -+++ pkg-config-0.23/configure.in 2010-06-22 13:05:58.951984140 +0100 -@@ -125,6 +125,14 @@ - AC_CONFIG_SUBDIRS(glib-1.2.10) - fi # !native_win32 +--- pkg-config-0.25.orig/configure.in 2011-10-05 18:52:24.879726050 +0100 ++++ pkg-config-0.25/configure.in 2011-10-05 18:55:39.639726152 +0100 +@@ -151,6 +151,18 @@ + AC_SUBST([POPT_LIBS]) + AM_CONDITIONAL([USE_INSTALLED_POPT], [test "x$with_installed_popt" = xyes]) +# legacy *-configure scripts can cause headaches, add option to disable +AC_ARG_ENABLE(legacy-scripts, @@ -21,20 +21,24 @@ Index: pkg-config-0.23/configure.in + [Whether pkg-config will try and use legacy scripts such as glib-config and gnome-config @<:@default=yes@:>@])], + [], + [enable_legacy=yes]) -+AM_CONDITIONAL([LEGACY_SCRIPTS], [test x$enable_legacy = xyes]) ++AM_CONDITIONAL([NO_LEGACY_SCRIPTS], [test x$enable_legacy != xyes]) ++if test x$enable_legacy != xyes; then ++ AC_DEFINE(NO_LEGACY_SCRIPTS, 1, [We are not using legacy scripts]) ++fi ++ + AC_FUNC_ALLOCA AC_CHECK_FUNCS(setresuid setreuid,break) -Index: pkg-config-0.23/parse.c +Index: pkg-config-0.25/parse.c =================================================================== ---- pkg-config-0.23.orig/parse.c 2008-01-16 20:42:49.000000000 +0000 -+++ pkg-config-0.23/parse.c 2010-06-22 13:09:10.410129471 +0100 -@@ -1195,6 +1195,11 @@ +--- pkg-config-0.25.orig/parse.c 2011-10-05 18:52:24.869726050 +0100 ++++ pkg-config-0.25/parse.c 2011-10-05 18:54:49.909726133 +0100 +@@ -1237,6 +1237,11 @@ * messages. */ return NULL; -+#elif defined(LEGACY_SCRIPTS) ++#elif defined(NO_LEGACY_SCRIPTS) + /* There are scenarios where we might not want to use these legacy + * scripts even if they are available. + */ diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb b/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb index a1f95083b3..76c0df916d 100644 --- a/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb +++ b/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb @@ -1,6 +1,6 @@ require pkgconfig.inc -PR = "r0" +PR = "r2" SRC_URI[md5sum] = "a3270bab3f4b69b7dc6dbdacbcae9745" SRC_URI[sha256sum] = "3ba691ee2431f32ccb8efa131e59bf23e37f122dc66791309023ca6dcefcd10e" diff --git a/meta/recipes-devtools/pseudo/pseudo.inc b/meta/recipes-devtools/pseudo/pseudo.inc index 0416a53d7d..0c7185b85b 100644 --- a/meta/recipes-devtools/pseudo/pseudo.inc +++ b/meta/recipes-devtools/pseudo/pseudo.inc @@ -10,8 +10,14 @@ LICENSE = "LGPL2.1" DEPENDS = "sqlite3" FILES_${PN} = "${libdir}/libpseudo.so ${bindir}/* ${localstatedir}/pseudo" +FILES_${PN}-dbg += "${libdir}/pseudo/lib*/.debug" PROVIDES += "virtual/fakeroot" +# In the nativesdk case, we'll already search the searchpaths +# pseudo tries to build in so override RPATH +MAKEOPTS = "" +MAKEOPTS_virtclass-nativesdk = "'RPATH='" + inherit siteinfo do_configure () { @@ -27,7 +33,7 @@ do_compile () { else ${S}/configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS} fi - oe_runmake + oe_runmake ${MAKEOPTS} } # Two below are the same @@ -37,9 +43,9 @@ do_compile_prepend_virtclass-native () { if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" == "pseudo-native" -a "${NO32LIBS}" != "1" ]; then # We need the 32-bit libpseudo on a 64-bit machine... ./configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 - oe_runmake libpseudo + oe_runmake ${MAKEOPTS} libpseudo # prevent it from removing the lib, but remove everything else - make 'LIB=foo' distclean + make 'LIB=foo' ${MAKEOPTS} distclean fi } @@ -47,14 +53,14 @@ do_compile_prepend_virtclass-nativesdk () { if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" == "pseudo-native" -a "${NO32LIBS}" != "1" ]; then # We need the 32-bit libpseudo on a 64-bit machine... ./configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 - oe_runmake libpseudo + oe_runmake ${MAKEOPTS} libpseudo # prevent it from removing the lib, but remove everything else - make 'LIB=foo' distclean + make 'LIB=foo' ${MAKEOPTS} distclean fi } do_install () { - oe_runmake 'DESTDIR=${D}' 'LIB=lib/pseudo/lib$(MARK64)' install + oe_runmake 'DESTDIR=${D}' ${MAKEOPTS} 'LIB=lib/pseudo/lib$(MARK64)' install } # Two below are the same diff --git a/meta/recipes-devtools/python/python/remove_sqlite_rpath.patch b/meta/recipes-devtools/python/python/remove_sqlite_rpath.patch new file mode 100644 index 0000000000..4ec627ea51 --- /dev/null +++ b/meta/recipes-devtools/python/python/remove_sqlite_rpath.patch @@ -0,0 +1,19 @@ +This patch removes the RPATH setting which contains a pointer to +the target relocated sysroot, which is incorrect. + +Upstream-Status: Inappropriate [Embedded Specific] + +Signed-off-by: Saul Wold <sgw@linux.intel.com> + +Index: Python-2.6.6/setup.py +=================================================================== +--- Python-2.6.6.orig/setup.py 2011-09-28 14:22:57.000000000 -0700 ++++ Python-2.6.6/setup.py 2011-09-28 16:11:25.147279633 -0700 +@@ -1079,7 +1079,6 @@ + include_dirs=["Modules/_sqlite", + sqlite_incdir], + library_dirs=sqlite_libdir, +- runtime_library_dirs=sqlite_libdir, + extra_link_args=sqlite_extra_link_args, + libraries=["sqlite3",])) + else: diff --git a/meta/recipes-devtools/python/python/setup_py_skip_cross_import_check.patch b/meta/recipes-devtools/python/python/setup_py_skip_cross_import_check.patch new file mode 100644 index 0000000000..6ccdb948b9 --- /dev/null +++ b/meta/recipes-devtools/python/python/setup_py_skip_cross_import_check.patch @@ -0,0 +1,27 @@ +This patch skips over the 'import check' setup.py does when building +extensions. This generally won't work when cross-compiling. + +Upstream-Status: Inappropriate [embedded-specific] + +Signed-off-by: Tom Zanussi <tom.zanussi@intel.com> + +Index: Python-2.7.2/setup.py +=================================================================== +--- Python-2.7.2.orig/setup.py 2011-11-04 16:46:34.553796410 -0500 ++++ Python-2.7.2/setup.py 2011-11-04 16:59:49.692802313 -0500 +@@ -287,6 +287,15 @@ + (ext.name, sys.exc_info()[1])) + self.failed.append(ext.name) + return ++ ++ # If we're cross-compiling, we want to skip the import check ++ # i.e. we shouldn't be dynamically loading target shared libs ++ if os.environ.get('CROSS_COMPILE') is not None: ++ self.announce( ++ 'WARNING: skipping import check for cross-compiled "%s"' % ++ ext.name) ++ return ++ + # Workaround for Mac OS X: The Carbon-based modules cannot be + # reliably imported into a command-line Python + if 'Carbon' in ext.extra_link_args: diff --git a/meta/recipes-devtools/python/python_2.6.6.bb b/meta/recipes-devtools/python/python_2.6.6.bb index aa7ec3c699..b3f79a377d 100644 --- a/meta/recipes-devtools/python/python_2.6.6.bb +++ b/meta/recipes-devtools/python/python_2.6.6.bb @@ -1,7 +1,7 @@ require python.inc DEPENDS = "python-native db gdbm openssl readline sqlite3 zlib" DEPENDS_sharprom = "python-native db readline zlib gdbm openssl" -PR = "${INC_PR}.10" +PR = "${INC_PR}.11" LIC_FILES_CHKSUM = "file://LICENSE;md5=38fdd546420fab09ac6bd3d8a1c83eb6" DISTRO_SRC_URI ?= "file://sitecustomize.py" @@ -21,6 +21,8 @@ SRC_URI = "\ file://multilib.patch \ file://security_issue_2254_fix.patch \ file://cgi_py.patch \ + file://remove_sqlite_rpath.patch \ + file://setup_py_skip_cross_import_check.patch \ " SRC_URI[md5sum] = "cf4e6881bb84a7ce6089e4a307f71f14" @@ -61,6 +63,8 @@ do_compile() { # then call do_install twice we get Makefile.orig == Makefile.sysroot install -m 0644 Makefile Makefile.sysroot + export CROSS_COMPILE="${TARGET_PREFIX}" + oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/pgen \ HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python \ STAGING_LIBDIR=${STAGING_LIBDIR} \ @@ -82,6 +86,8 @@ do_install() { # make install needs the original Makefile, or otherwise the inclues would # go to ${D}${STAGING...}/... install -m 0644 Makefile.orig Makefile + + export CROSS_COMPILE="${TARGET_PREFIX}" oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/pgen \ HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python \ diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index 86c7d2c1fa..58049b98f3 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -12,7 +12,7 @@ SDL ?= "--disable-sdl" SDL_virtclass-native ?= "" SDL_virtclass-nativesdk ?= "" -EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror --disable-vnc-tls --enable-kvm --audio-drv-list=oss,alsa --audio-card-list=ac97,es1370 ${SDL}" +EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror --disable-vnc-tls --audio-drv-list=oss,alsa --audio-card-list=ac97,es1370 ${SDL}" #EXTRA_OECONF += "--disable-sdl" @@ -39,7 +39,13 @@ do_configure_prepend_virtclass-native() { } do_configure() { - ${S}/configure --prefix=${prefix} --sysconfdir=${sysconfdir} --disable-strip ${EXTRA_OECONF} + # Handle distros such as CentOS 5 32-bit that do not have kvm support + KVMOPTS="" + if [ "${PN}" != "qemu-native" ] || [ -f /usr/include/linux/kvm.h ] ; then + KVMOPTS="--enable-kvm" + fi + + ${S}/configure --prefix=${prefix} --sysconfdir=${sysconfdir} --disable-strip ${EXTRA_OECONF} $KVMOPTS test ! -e ${S}/target-i386/beginend_funcs.sh || chmod a+x ${S}/target-i386/beginend_funcs.sh } diff --git a/meta/recipes-devtools/qemu/qemu_0.14.0.bb b/meta/recipes-devtools/qemu/qemu_0.14.0.bb index 03519ad7d4..5a0cd55bb9 100644 --- a/meta/recipes-devtools/qemu/qemu_0.14.0.bb +++ b/meta/recipes-devtools/qemu/qemu_0.14.0.bb @@ -3,7 +3,7 @@ require qemu.inc LIC_FILES_CHKSUM = "file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \ file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913" -PR = "r3" +PR = "r4" FILESPATH = "${FILE_DIRNAME}/qemu-${PV}" FILESDIR = "${WORKDIR}" diff --git a/meta/recipes-devtools/qemu/qemu_git.bb b/meta/recipes-devtools/qemu/qemu_git.bb index 59fc7f1396..3b4369b782 100644 --- a/meta/recipes-devtools/qemu/qemu_git.bb +++ b/meta/recipes-devtools/qemu/qemu_git.bb @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \ file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913" PV = "0.14.0" -PR = "r1" +PR = "r2" FILESPATH = "${FILE_DIRNAME}/qemu-${PV}/:${FILE_DIRNAME}/qemu-git/" FILESDIR = "${WORKDIR}" diff --git a/meta/recipes-devtools/rpm/rpm/rpm-log-auto-rm.patch b/meta/recipes-devtools/rpm/rpm/rpm-log-auto-rm.patch new file mode 100644 index 0000000000..aafa416881 --- /dev/null +++ b/meta/recipes-devtools/rpm/rpm/rpm-log-auto-rm.patch @@ -0,0 +1,12 @@ +diff --git a/rpmdb/DB_CONFIG.in b/rpmdb/DB_CONFIG.in +index 8b94c94..e0b4689 100644 +--- a/rpmdb/DB_CONFIG.in ++++ b/rpmdb/DB_CONFIG.in +@@ -4,6 +4,7 @@ set_data_dir . + set_create_dir . + set_lg_dir ./log + set_tmp_dir ./tmp ++set_flags db_log_autoremove on + + # -- thread_count must be >= 8 + set_thread_count 64 diff --git a/meta/recipes-devtools/rpm/rpm/rpm-scriptletexechelper.patch b/meta/recipes-devtools/rpm/rpm/rpm-scriptletexechelper.patch new file mode 100644 index 0000000000..e4db0e4211 --- /dev/null +++ b/meta/recipes-devtools/rpm/rpm/rpm-scriptletexechelper.patch @@ -0,0 +1,159 @@ +Enable a cross-install scriptlet helper. + +The helper is called from outside of the chroot with the arguments: + +<root> <prog> <script> <arg1> [<arg2> ... <argN>] + +The helper script is used by oe-core to facilitate shell script actions that +can not be run from within a chroot on a foreign target system during a +cross install. + +Upstream-Status: Pending + +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> + +diff -ur rpm-5.4.0.orig/lib/psm.c rpm-5.4.0/lib/psm.c +--- rpm-5.4.0.orig/lib/psm.c 2010-12-29 07:42:11.000000000 -0600 ++++ rpm-5.4.0/lib/psm.c 2011-11-08 13:38:48.132791154 -0600 +@@ -792,6 +792,10 @@ + int xx; + int i; + ++#ifdef RPM_VENDOR_POKY ++ const char * scriptletWrapper = rpmExpand("%{?_cross_scriptlet_wrapper}", NULL); ++#endif ++ + if (psm->sstates != NULL && ix >= 0 && ix < RPMSCRIPT_MAX) + ssp = psm->sstates + ix; + if (ssp != NULL) +@@ -858,14 +862,29 @@ + (F_ISSET(psm, UNORDERED) ? "a" : "")); + + if (Phe->p.argv == NULL) { +- argv = alloca(5 * sizeof(*argv)); +- argv[0] = "/bin/sh"; +- argc = 1; ++ argv = alloca(7 * sizeof(*argv)); ++ argc = 0; ++ } else { ++ argv = alloca((Phe->c + 6) * sizeof(*argv)); ++ argc = 0; ++ } ++ ++#ifdef RPM_VENDOR_POKY ++ if (scriptletWrapper && *scriptletWrapper) { ++ argv[argc++] = scriptletWrapper; ++ argv[argc] = rpmtsRootDir(ts); ++ if (!argv[argc] || !*argv[argc]) ++ argv[argc] = "/"; ++ argc++; ++ } ++#endif ++ ++ if (Phe->p.argv == NULL) { ++ argv[argc++] = "/bin/sh"; + ldconfig_done = 0; + } else { +- argv = alloca((Phe->c + 4) * sizeof(*argv)); +- memcpy(argv, Phe->p.argv, Phe->c * sizeof(*argv)); +- argc = Phe->c; ++ memcpy((argv + argc), Phe->p.argv, Phe->c * sizeof(*argv)); ++ argc += Phe->c; + ldconfig_done = (ldconfig_path && !strcmp(argv[0], ldconfig_path) + ? 1 : 0); + } +@@ -916,7 +935,12 @@ + goto exit; + + if (rpmIsDebug() && +- (!strcmp(argv[0], "/bin/sh") || !strcmp(argv[0], "/bin/bash"))) ++ (!strcmp(argv[0], "/bin/sh") || !strcmp(argv[0], "/bin/bash")) ++#ifdef RPM_VENDOR_POKY ++ || (scriptletWrapper && *scriptletWrapper && !strcmp(argv[1], "/bin/sh")) ++ || (scriptletWrapper && *scriptletWrapper && !strcmp(argv[1], "/bin/bash")) ++#endif ++ ) + { + static const char set_x[] = "set -x\n"; + nw = Fwrite(set_x, sizeof(set_x[0]), sizeof(set_x)-1, fd); +@@ -1051,12 +1075,22 @@ + + { const char * rootDir = rpmtsRootDir(ts); + if (!rpmtsChrootDone(ts) && rootDir != NULL && ++#ifdef RPM_VENDOR_POKY ++ !(scriptletWrapper && *scriptletWrapper) && ++#endif + !(rootDir[0] == '/' && rootDir[1] == '\0')) + { + /*@-modobserver@*/ + xx = Chroot(rootDir); + /*@=modobserver@*/ + } ++#ifdef RPM_VENDOR_POKY ++ if (!rpmtsChrootDone(ts) && rootDir != NULL && ++ (scriptletWrapper && *scriptletWrapper) && ++ !(rootDir[0] == '/' && rootDir[1] == '\0')) ++ xx = Chdir(rootDir); ++ else ++#endif + xx = Chdir("/"); + rpmlog(RPMLOG_DEBUG, D_("%s: %s(%s)\texecv(%s) pid %d\n"), + psm->stepName, sln, NVRA, +@@ -2961,6 +2995,13 @@ + case PSM_SCRIPT: /* Run current package scriptlets. */ + /* XXX running %verifyscript/%sanitycheck doesn't have psm->te */ + { rpmtxn _parent = (psm && psm->te ? psm->te->txn : NULL); ++ ++#ifdef RPM_VENDOR_POKY ++ const char * scriptletWrapper = rpmExpand("%{?_cross_scriptlet_wrapper}", NULL); ++ if (scriptletWrapper && *scriptletWrapper) ++ rc = rpmpsmNext(psm, PSM_CHROOT_OUT); ++#endif ++ + xx = rpmtxnBegin(rpmtsGetRdb(ts), _parent, NULL); + rc = runInstScript(psm); + if (rc) +@@ -2968,11 +3009,24 @@ + else + xx = rpmtxnCommit(rpmtsGetRdb(ts)->db_txn); + rpmtsGetRdb(ts)->db_txn = NULL; ++#ifdef RPM_VENDOR_POKY ++ if (scriptletWrapper && *scriptletWrapper) ++ rc = rpmpsmNext(psm, PSM_CHROOT_IN); ++#endif + } break; + case PSM_TRIGGERS: + /* Run triggers in other package(s) this package sets off. */ + if (rpmtsFlags(ts) & RPMTRANS_FLAG_TEST) break; ++#ifdef RPM_VENDOR_POKY ++ const char * scriptletWrapper = rpmExpand("%{?_cross_scriptlet_wrapper}", NULL); ++ if (scriptletWrapper && *scriptletWrapper) ++ rc = rpmpsmNext(psm, PSM_CHROOT_OUT); ++#endif + rc = runTriggers(psm); ++#ifdef RPM_VENDOR_POKY ++ if (scriptletWrapper && *scriptletWrapper) ++ rc = rpmpsmNext(psm, PSM_CHROOT_IN); ++#endif + break; + case PSM_IMMED_TRIGGERS: + /* Run triggers in this package other package(s) set off. */ +@@ -2982,7 +3036,18 @@ + F_SET(psm, GOTTRIGGERS); + } + if (psm->triggers != NULL) ++#ifdef RPM_VENDOR_POKY ++ { ++ const char * scriptletWrapper = rpmExpand("%{?_cross_scriptlet_wrapper}", NULL); ++ if (scriptletWrapper && *scriptletWrapper) ++ rc = rpmpsmNext(psm, PSM_CHROOT_OUT); ++#endif + rc = runImmedTriggers(psm); ++#ifdef RPM_VENDOR_POKY ++ if (scriptletWrapper && *scriptletWrapper) ++ rc = rpmpsmNext(psm, PSM_CHROOT_IN); ++ } ++#endif + break; + + case PSM_RPMIO_FLAGS: diff --git a/meta/recipes-devtools/rpm/rpm_5.4.0.bb b/meta/recipes-devtools/rpm/rpm_5.4.0.bb index 356512aa5d..7795914a70 100644 --- a/meta/recipes-devtools/rpm/rpm_5.4.0.bb +++ b/meta/recipes-devtools/rpm/rpm_5.4.0.bb @@ -45,11 +45,12 @@ LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1" DEPENDS = "bzip2 zlib db openssl elfutils expat libpcre attr acl popt ${extrarpmdeps}" extrarpmdeps = "python perl" extrarpmdeps_virtclass-native = "file-native" -PR = "r22" +PR = "r25" # rpm2cpio is a shell script, which is part of the rpm src.rpm. It is needed # in order to extract the distribution SRPM into a format we can extract... SRC_URI = "http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.0-0.20101229.src.rpm;extract=rpm-5.4.0.tar.gz \ + file://rpm-log-auto-rm.patch \ file://perfile_rpmdeps.sh \ file://rpm-autogen.patch \ file://rpm-libsql-fix.patch \ @@ -63,6 +64,7 @@ SRC_URI = "http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.0-0.20101229.src.rpm;ex file://rpm-fileclass.patch \ file://rpm-canonarch.patch \ file://rpm-no-loopmsg.patch \ + file://rpm-scriptletexechelper.patch \ file://pythondeps.sh \ " @@ -155,6 +157,7 @@ EXTRA_OECONF = "--verbose \ --with-build-extlibdep \ --with-build-maxextlibdep \ --without-valgrind \ + --without-xz \ --disable-openmp \ --enable-build-pic \ --enable-build-versionscript \ @@ -168,7 +171,7 @@ EXTRA_OECONF = "--verbose \ CFLAGS_append = " -DRPM_VENDOR_WINDRIVER -DRPM_VENDOR_POKY" -PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-libs ${PN}-dev ${PN}-common ${PN}-build python-rpm-dbg python-rpm perl-module-rpm perl-module-rpm-dev ${PN}-locale" +PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-libs ${PN}-dev ${PN}-staticdev ${PN}-common ${PN}-build python-rpm-dbg python-rpm perl-module-rpm perl-module-rpm-dev ${PN}-locale" SOLIBS = "5.4.so" @@ -191,6 +194,7 @@ FILES_${PN} = "${bindir}/rpm \ ${libdir}/rpm/bin/rpmrepo \ ${libdir}/rpm/bin/rpmspecdump \ ${libdir}/rpm/bin/wget \ + /var/lib/rpm \ " # ${libdir}/rpm/magic @@ -207,7 +211,6 @@ FILES_${PN}-dbg += "${libdir}/rpm/.debug \ FILES_${PN}-common = "${bindir}/rpm2cpio \ ${bindir}/gendiff \ /etc/rpm \ - /var/lib/rpm \ /var/spool/repackage \ " @@ -304,27 +307,30 @@ FILES_perl-module-rpm-dev = "${prefix}/share/man/man3/RPM* \ " FILE_${PN}-dev = "${includedir}/rpm \ - ${libdir}/librpm.a \ ${libdir}/librpm.la \ ${libdir}/librpm.so \ - ${libdir}/librpmconstant.a \ ${libdir}/librpmconstant.la \ ${libdir}/librpmconstant.so \ - ${libdir}/librpmdb.a \ ${libdir}/librpmdb.la \ ${libdir}/librpmdb.so \ - ${libdir}/librpmio.a \ ${libdir}/librpmio.la \ ${libdir}/librpmio.so \ - ${libdir}/librpmmisc.a \ ${libdir}/librpmmisc.la \ ${libdir}/librpmmisc.so \ - ${libdir}/librpmbuild.a \ ${libdir}/librpmbuild.la \ ${libdir}/librpmbuild.so \ ${libdir}/pkgconfig/rpm.pc \ " +FILE_${PN}-staticdev = " \ + ${libdir}/librpm.a \ + ${libdir}/librpmconstant.a \ + ${libdir}/librpmdb.a \ + ${libdir}/librpmio.a \ + ${libdir}/librpmmisc.a \ + ${libdir}/librpmbuild.a \ + " + ###%{_rpmhome}/lib/libxar.a ###%{_rpmhome}/lib/libxar.la ###%{_rpmhome}/lib/libxar.so diff --git a/meta/recipes-devtools/strace/strace_4.5.20.bb b/meta/recipes-devtools/strace/strace_4.5.20.bb index 391669f5da..b3d2aa53ef 100644 --- a/meta/recipes-devtools/strace/strace_4.5.20.bb +++ b/meta/recipes-devtools/strace/strace_4.5.20.bb @@ -5,6 +5,8 @@ LICENSE = "BSD" LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=4535377ede62550fdeaf39f595fd550a" PR = "r2" +RDEPENDS = "perl" + SRC_URI = "${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.bz2 \ file://sigmask.patch \ " diff --git a/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch b/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch new file mode 100644 index 0000000000..c9852ef07a --- /dev/null +++ b/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch @@ -0,0 +1,975 @@ +From a1006762fa6f98750bb77d76dd992cb8ea9f9c99 Mon Sep 17 00:00:00 2001 +Message-Id: <a1006762fa6f98750bb77d76dd992cb8ea9f9c99.1333550572.git.dvhart@linux.intel.com> +From: "H. Peter Anvin" <hpa@zytor.com> +Date: Mon, 26 Mar 2012 22:51:09 -0700 +Subject: [PATCH] libinstaller: Avoid using <linux/ext2_fs.h> + +Don't use <linux/ext2_fs.h> if we can avoid it. + +Upstream-Status: Available in syslinux-4.06-pre3 + +The ioctl constants have been globalized and moved to <linux/fs.h>. +Use a private copy of ext2_fs.h from e2fsprogs with the ioctl +constants removed for the data structures. + +Do at least attempt backward compatibility for old kernel headers, but +no real hope of proper operation there... + +Signed-off-by: H. Peter Anvin <hpa@zytor.com> + +Massaged into 4.03. + +Integrated-by: Darren Hart <dvhart@linux.intel.com> +--- + libinstaller/ext2fs/ext2_fs.h | 856 +++++++++++++++++++++++++++++++++++++++++ + libinstaller/linuxioctl.h | 29 ++- + libinstaller/syslxcom.c | 12 +- + 3 files changed, 886 insertions(+), 11 deletions(-) + create mode 100644 libinstaller/ext2fs/ext2_fs.h + +Index: syslinux-4.03/libinstaller/ext2fs/ext2_fs.h +=================================================================== +--- /dev/null ++++ syslinux-4.03/libinstaller/ext2fs/ext2_fs.h +@@ -0,0 +1,856 @@ ++/* ++ * linux/include/linux/ext2_fs.h ++ * ++ * Copyright (C) 1992, 1993, 1994, 1995 ++ * Remy Card (card@masi.ibp.fr) ++ * Laboratoire MASI - Institut Blaise Pascal ++ * Universite Pierre et Marie Curie (Paris VI) ++ * ++ * from ++ * ++ * linux/include/linux/minix_fs.h ++ * ++ * Copyright (C) 1991, 1992 Linus Torvalds ++ */ ++ ++#ifndef _EXT2FS_EXT2_FS_H ++#define _EXT2FS_EXT2_FS_H ++ ++#include <linux/types.h> ++ ++/* ++ * The second extended filesystem constants/structures ++ */ ++ ++/* ++ * Define EXT2FS_DEBUG to produce debug messages ++ */ ++#undef EXT2FS_DEBUG ++ ++/* ++ * Define EXT2_PREALLOCATE to preallocate data blocks for expanding files ++ */ ++#define EXT2_PREALLOCATE ++#define EXT2_DEFAULT_PREALLOC_BLOCKS 8 ++ ++/* ++ * The second extended file system version ++ */ ++#define EXT2FS_DATE "95/08/09" ++#define EXT2FS_VERSION "0.5b" ++ ++/* ++ * Special inode numbers ++ */ ++#define EXT2_BAD_INO 1 /* Bad blocks inode */ ++#define EXT2_ROOT_INO 2 /* Root inode */ ++#define EXT4_USR_QUOTA_INO 3 /* User quota inode */ ++#define EXT4_GRP_QUOTA_INO 4 /* Group quota inode */ ++#define EXT2_BOOT_LOADER_INO 5 /* Boot loader inode */ ++#define EXT2_UNDEL_DIR_INO 6 /* Undelete directory inode */ ++#define EXT2_RESIZE_INO 7 /* Reserved group descriptors inode */ ++#define EXT2_JOURNAL_INO 8 /* Journal inode */ ++#define EXT2_EXCLUDE_INO 9 /* The "exclude" inode, for snapshots */ ++#define EXT4_REPLICA_INO 10 /* Used by non-upstream feature */ ++ ++/* First non-reserved inode for old ext2 filesystems */ ++#define EXT2_GOOD_OLD_FIRST_INO 11 ++ ++/* ++ * The second extended file system magic number ++ */ ++#define EXT2_SUPER_MAGIC 0xEF53 ++ ++#ifdef __KERNEL__ ++#define EXT2_SB(sb) (&((sb)->u.ext2_sb)) ++#else ++/* Assume that user mode programs are passing in an ext2fs superblock, not ++ * a kernel struct super_block. This will allow us to call the feature-test ++ * macros from user land. */ ++#define EXT2_SB(sb) (sb) ++#endif ++ ++/* ++ * Maximal count of links to a file ++ */ ++#define EXT2_LINK_MAX 65000 ++ ++/* ++ * Macro-instructions used to manage several block sizes ++ */ ++#define EXT2_MIN_BLOCK_LOG_SIZE 10 /* 1024 */ ++#define EXT2_MAX_BLOCK_LOG_SIZE 16 /* 65536 */ ++#define EXT2_MIN_BLOCK_SIZE (1 << EXT2_MIN_BLOCK_LOG_SIZE) ++#define EXT2_MAX_BLOCK_SIZE (1 << EXT2_MAX_BLOCK_LOG_SIZE) ++#ifdef __KERNEL__ ++#define EXT2_BLOCK_SIZE(s) ((s)->s_blocksize) ++#define EXT2_BLOCK_SIZE_BITS(s) ((s)->s_blocksize_bits) ++#define EXT2_ADDR_PER_BLOCK_BITS(s) (EXT2_SB(s)->addr_per_block_bits) ++#define EXT2_INODE_SIZE(s) (EXT2_SB(s)->s_inode_size) ++#define EXT2_FIRST_INO(s) (EXT2_SB(s)->s_first_ino) ++#else ++#define EXT2_BLOCK_SIZE(s) (EXT2_MIN_BLOCK_SIZE << (s)->s_log_block_size) ++#define EXT2_BLOCK_SIZE_BITS(s) ((s)->s_log_block_size + 10) ++#define EXT2_INODE_SIZE(s) (((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \ ++ EXT2_GOOD_OLD_INODE_SIZE : (s)->s_inode_size) ++#define EXT2_FIRST_INO(s) (((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \ ++ EXT2_GOOD_OLD_FIRST_INO : (s)->s_first_ino) ++#endif ++#define EXT2_ADDR_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s) / sizeof(__u32)) ++ ++/* ++ * Macro-instructions used to manage allocation clusters ++ */ ++#define EXT2_MIN_CLUSTER_LOG_SIZE EXT2_MIN_BLOCK_LOG_SIZE ++#define EXT2_MAX_CLUSTER_LOG_SIZE 29 /* 512MB */ ++#define EXT2_MIN_CLUSTER_SIZE EXT2_MIN_BLOCK_SIZE ++#define EXT2_MAX_CLUSTER_SIZE (1 << EXT2_MAX_CLUSTER_LOG_SIZE) ++#define EXT2_CLUSTER_SIZE(s) (EXT2_MIN_BLOCK_SIZE << \ ++ (s)->s_log_cluster_size) ++#define EXT2_CLUSTER_SIZE_BITS(s) ((s)->s_log_cluster_size + 10) ++ ++/* ++ * Macro-instructions used to manage fragments ++ * ++ * Note: for backwards compatibility only, for the dump program. ++ * Ext2/3/4 will never support fragments.... ++ */ ++#define EXT2_MIN_FRAG_SIZE EXT2_MIN_BLOCK_SIZE ++#define EXT2_MAX_FRAG_SIZE EXT2_MAX_BLOCK_SIZE ++#define EXT2_MIN_FRAG_LOG_SIZE EXT2_MIN_BLOCK_LOG_SIZE ++#define EXT2_FRAG_SIZE(s) EXT2_BLOCK_SIZE(s) ++#define EXT2_FRAGS_PER_BLOCK(s) 1 ++ ++/* ++ * ACL structures ++ */ ++struct ext2_acl_header /* Header of Access Control Lists */ ++{ ++ __u32 aclh_size; ++ __u32 aclh_file_count; ++ __u32 aclh_acle_count; ++ __u32 aclh_first_acle; ++}; ++ ++struct ext2_acl_entry /* Access Control List Entry */ ++{ ++ __u32 acle_size; ++ __u16 acle_perms; /* Access permissions */ ++ __u16 acle_type; /* Type of entry */ ++ __u16 acle_tag; /* User or group identity */ ++ __u16 acle_pad1; ++ __u32 acle_next; /* Pointer on next entry for the */ ++ /* same inode or on next free entry */ ++}; ++ ++/* ++ * Structure of a blocks group descriptor ++ */ ++struct ext2_group_desc ++{ ++ __u32 bg_block_bitmap; /* Blocks bitmap block */ ++ __u32 bg_inode_bitmap; /* Inodes bitmap block */ ++ __u32 bg_inode_table; /* Inodes table block */ ++ __u16 bg_free_blocks_count; /* Free blocks count */ ++ __u16 bg_free_inodes_count; /* Free inodes count */ ++ __u16 bg_used_dirs_count; /* Directories count */ ++ __u16 bg_flags; ++ __u32 bg_exclude_bitmap_lo; /* Exclude bitmap for snapshots */ ++ __u16 bg_block_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */ ++ __u16 bg_inode_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */ ++ __u16 bg_itable_unused; /* Unused inodes count */ ++ __u16 bg_checksum; /* crc16(s_uuid+grouo_num+group_desc)*/ ++}; ++ ++/* ++ * Structure of a blocks group descriptor ++ */ ++struct ext4_group_desc ++{ ++ __u32 bg_block_bitmap; /* Blocks bitmap block */ ++ __u32 bg_inode_bitmap; /* Inodes bitmap block */ ++ __u32 bg_inode_table; /* Inodes table block */ ++ __u16 bg_free_blocks_count; /* Free blocks count */ ++ __u16 bg_free_inodes_count; /* Free inodes count */ ++ __u16 bg_used_dirs_count; /* Directories count */ ++ __u16 bg_flags; /* EXT4_BG_flags (INODE_UNINIT, etc) */ ++ __u32 bg_exclude_bitmap_lo; /* Exclude bitmap for snapshots */ ++ __u16 bg_block_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */ ++ __u16 bg_inode_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */ ++ __u16 bg_itable_unused; /* Unused inodes count */ ++ __u16 bg_checksum; /* crc16(sb_uuid+group+desc) */ ++ __u32 bg_block_bitmap_hi; /* Blocks bitmap block MSB */ ++ __u32 bg_inode_bitmap_hi; /* Inodes bitmap block MSB */ ++ __u32 bg_inode_table_hi; /* Inodes table block MSB */ ++ __u16 bg_free_blocks_count_hi;/* Free blocks count MSB */ ++ __u16 bg_free_inodes_count_hi;/* Free inodes count MSB */ ++ __u16 bg_used_dirs_count_hi; /* Directories count MSB */ ++ __u16 bg_itable_unused_hi; /* Unused inodes count MSB */ ++ __u32 bg_exclude_bitmap_hi; /* Exclude bitmap block MSB */ ++ __u16 bg_block_bitmap_csum_hi;/* crc32c(s_uuid+grp_num+bitmap) MSB */ ++ __u16 bg_inode_bitmap_csum_hi;/* crc32c(s_uuid+grp_num+bitmap) MSB */ ++ __u32 bg_reserved; ++}; ++ ++#define EXT2_BG_INODE_UNINIT 0x0001 /* Inode table/bitmap not initialized */ ++#define EXT2_BG_BLOCK_UNINIT 0x0002 /* Block bitmap not initialized */ ++#define EXT2_BG_INODE_ZEROED 0x0004 /* On-disk itable initialized to zero */ ++ ++/* ++ * Data structures used by the directory indexing feature ++ * ++ * Note: all of the multibyte integer fields are little endian. ++ */ ++ ++/* ++ * Note: dx_root_info is laid out so that if it should somehow get ++ * overlaid by a dirent the two low bits of the hash version will be ++ * zero. Therefore, the hash version mod 4 should never be 0. ++ * Sincerely, the paranoia department. ++ */ ++struct ext2_dx_root_info { ++ __u32 reserved_zero; ++ __u8 hash_version; /* 0 now, 1 at release */ ++ __u8 info_length; /* 8 */ ++ __u8 indirect_levels; ++ __u8 unused_flags; ++}; ++ ++#define EXT2_HASH_LEGACY 0 ++#define EXT2_HASH_HALF_MD4 1 ++#define EXT2_HASH_TEA 2 ++#define EXT2_HASH_LEGACY_UNSIGNED 3 /* reserved for userspace lib */ ++#define EXT2_HASH_HALF_MD4_UNSIGNED 4 /* reserved for userspace lib */ ++#define EXT2_HASH_TEA_UNSIGNED 5 /* reserved for userspace lib */ ++ ++#define EXT2_HASH_FLAG_INCOMPAT 0x1 ++ ++struct ext2_dx_entry { ++ __u32 hash; ++ __u32 block; ++}; ++ ++struct ext2_dx_countlimit { ++ __u16 limit; ++ __u16 count; ++}; ++ ++ ++/* ++ * Macro-instructions used to manage group descriptors ++ */ ++#define EXT2_MIN_DESC_SIZE 32 ++#define EXT2_MIN_DESC_SIZE_64BIT 64 ++#define EXT2_MAX_DESC_SIZE EXT2_MIN_BLOCK_SIZE ++#define EXT2_DESC_SIZE(s) \ ++ ((EXT2_SB(s)->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT) ? \ ++ (s)->s_desc_size : EXT2_MIN_DESC_SIZE) ++ ++#define EXT2_BLOCKS_PER_GROUP(s) (EXT2_SB(s)->s_blocks_per_group) ++#define EXT2_INODES_PER_GROUP(s) (EXT2_SB(s)->s_inodes_per_group) ++#define EXT2_CLUSTERS_PER_GROUP(s) (EXT2_SB(s)->s_clusters_per_group) ++#define EXT2_INODES_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s)) ++/* limits imposed by 16-bit value gd_free_{blocks,inode}_count */ ++#define EXT2_MAX_BLOCKS_PER_GROUP(s) ((((unsigned) 1 << 16) - 8) * \ ++ (EXT2_CLUSTER_SIZE(s) / \ ++ EXT2_BLOCK_SIZE(s))) ++#define EXT2_MAX_CLUSTERS_PER_GROUP(s) (((unsigned) 1 << 16) - 8) ++#define EXT2_MAX_INODES_PER_GROUP(s) (((unsigned) 1 << 16) - \ ++ EXT2_INODES_PER_BLOCK(s)) ++#ifdef __KERNEL__ ++#define EXT2_DESC_PER_BLOCK(s) (EXT2_SB(s)->s_desc_per_block) ++#define EXT2_DESC_PER_BLOCK_BITS(s) (EXT2_SB(s)->s_desc_per_block_bits) ++#else ++#define EXT2_DESC_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s) / EXT2_DESC_SIZE(s)) ++#endif ++ ++/* ++ * Constants relative to the data blocks ++ */ ++#define EXT2_NDIR_BLOCKS 12 ++#define EXT2_IND_BLOCK EXT2_NDIR_BLOCKS ++#define EXT2_DIND_BLOCK (EXT2_IND_BLOCK + 1) ++#define EXT2_TIND_BLOCK (EXT2_DIND_BLOCK + 1) ++#define EXT2_N_BLOCKS (EXT2_TIND_BLOCK + 1) ++ ++/* ++ * Inode flags ++ */ ++#define EXT2_SECRM_FL 0x00000001 /* Secure deletion */ ++#define EXT2_UNRM_FL 0x00000002 /* Undelete */ ++#define EXT2_COMPR_FL 0x00000004 /* Compress file */ ++#define EXT2_SYNC_FL 0x00000008 /* Synchronous updates */ ++#define EXT2_IMMUTABLE_FL 0x00000010 /* Immutable file */ ++#define EXT2_APPEND_FL 0x00000020 /* writes to file may only append */ ++#define EXT2_NODUMP_FL 0x00000040 /* do not dump file */ ++#define EXT2_NOATIME_FL 0x00000080 /* do not update atime */ ++/* Reserved for compression usage... */ ++#define EXT2_DIRTY_FL 0x00000100 ++#define EXT2_COMPRBLK_FL 0x00000200 /* One or more compressed clusters */ ++#define EXT2_NOCOMPR_FL 0x00000400 /* Access raw compressed data */ ++#define EXT2_ECOMPR_FL 0x00000800 /* Compression error */ ++/* End compression flags --- maybe not all used */ ++#define EXT2_BTREE_FL 0x00001000 /* btree format dir */ ++#define EXT2_INDEX_FL 0x00001000 /* hash-indexed directory */ ++#define EXT2_IMAGIC_FL 0x00002000 ++#define EXT3_JOURNAL_DATA_FL 0x00004000 /* file data should be journaled */ ++#define EXT2_NOTAIL_FL 0x00008000 /* file tail should not be merged */ ++#define EXT2_DIRSYNC_FL 0x00010000 /* Synchronous directory modifications */ ++#define EXT2_TOPDIR_FL 0x00020000 /* Top of directory hierarchies*/ ++#define EXT4_HUGE_FILE_FL 0x00040000 /* Set to each huge file */ ++#define EXT4_EXTENTS_FL 0x00080000 /* Inode uses extents */ ++#define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */ ++/* EXT4_EOFBLOCKS_FL 0x00400000 was here */ ++#define EXT4_SNAPFILE_FL 0x01000000 /* Inode is a snapshot */ ++#define EXT4_SNAPFILE_DELETED_FL 0x04000000 /* Snapshot is being deleted */ ++#define EXT4_SNAPFILE_SHRUNK_FL 0x08000000 /* Snapshot shrink has completed */ ++#define EXT2_RESERVED_FL 0x80000000 /* reserved for ext2 lib */ ++ ++#define EXT2_FL_USER_VISIBLE 0x004BDFFF /* User visible flags */ ++#define EXT2_FL_USER_MODIFIABLE 0x004B80FF /* User modifiable flags */ ++ ++/* ++ * ioctl commands ++ */ ++ ++/* Used for online resize */ ++struct ext2_new_group_input { ++ __u32 group; /* Group number for this data */ ++ __u32 block_bitmap; /* Absolute block number of block bitmap */ ++ __u32 inode_bitmap; /* Absolute block number of inode bitmap */ ++ __u32 inode_table; /* Absolute block number of inode table start */ ++ __u32 blocks_count; /* Total number of blocks in this group */ ++ __u16 reserved_blocks; /* Number of reserved blocks in this group */ ++ __u16 unused; /* Number of reserved GDT blocks in group */ ++}; ++ ++struct ext4_new_group_input { ++ __u32 group; /* Group number for this data */ ++ __u64 block_bitmap; /* Absolute block number of block bitmap */ ++ __u64 inode_bitmap; /* Absolute block number of inode bitmap */ ++ __u64 inode_table; /* Absolute block number of inode table start */ ++ __u32 blocks_count; /* Total number of blocks in this group */ ++ __u16 reserved_blocks; /* Number of reserved blocks in this group */ ++ __u16 unused; ++}; ++ ++#ifdef __GNU__ /* Needed for the Hurd */ ++#define _IOT_ext2_new_group_input _IOT (_IOTS(__u32), 5, _IOTS(__u16), 2, 0, 0) ++#endif ++ ++#define EXT2_IOC_GETFLAGS _IOR('f', 1, long) ++#define EXT2_IOC_SETFLAGS _IOW('f', 2, long) ++#define EXT2_IOC_GETVERSION _IOR('v', 1, long) ++#define EXT2_IOC_SETVERSION _IOW('v', 2, long) ++#define EXT2_IOC_GETVERSION_NEW _IOR('f', 3, long) ++#define EXT2_IOC_SETVERSION_NEW _IOW('f', 4, long) ++#define EXT2_IOC_GROUP_EXTEND _IOW('f', 7, unsigned long) ++#define EXT2_IOC_GROUP_ADD _IOW('f', 8,struct ext2_new_group_input) ++#define EXT4_IOC_GROUP_ADD _IOW('f', 8,struct ext4_new_group_input) ++#define EXT4_IOC_RESIZE_FS _IOW('f', 16, __u64) ++ ++/* ++ * Structure of an inode on the disk ++ */ ++struct ext2_inode { ++ __u16 i_mode; /* File mode */ ++ __u16 i_uid; /* Low 16 bits of Owner Uid */ ++ __u32 i_size; /* Size in bytes */ ++ __u32 i_atime; /* Access time */ ++ __u32 i_ctime; /* Inode change time */ ++ __u32 i_mtime; /* Modification time */ ++ __u32 i_dtime; /* Deletion Time */ ++ __u16 i_gid; /* Low 16 bits of Group Id */ ++ __u16 i_links_count; /* Links count */ ++ __u32 i_blocks; /* Blocks count */ ++ __u32 i_flags; /* File flags */ ++ union { ++ struct { ++ __u32 l_i_version; /* was l_i_reserved1 */ ++ } linux1; ++ struct { ++ __u32 h_i_translator; ++ } hurd1; ++ } osd1; /* OS dependent 1 */ ++ __u32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */ ++ __u32 i_generation; /* File version (for NFS) */ ++ __u32 i_file_acl; /* File ACL */ ++ __u32 i_size_high; /* Formerly i_dir_acl, directory ACL */ ++ __u32 i_faddr; /* Fragment address */ ++ union { ++ struct { ++ __u16 l_i_blocks_hi; ++ __u16 l_i_file_acl_high; ++ __u16 l_i_uid_high; /* these 2 fields */ ++ __u16 l_i_gid_high; /* were reserved2[0] */ ++ __u16 l_i_checksum_lo; /* crc32c(uuid+inum+inode) */ ++ __u16 l_i_reserved; ++ } linux2; ++ struct { ++ __u8 h_i_frag; /* Fragment number */ ++ __u8 h_i_fsize; /* Fragment size */ ++ __u16 h_i_mode_high; ++ __u16 h_i_uid_high; ++ __u16 h_i_gid_high; ++ __u32 h_i_author; ++ } hurd2; ++ } osd2; /* OS dependent 2 */ ++}; ++ ++/* ++ * Permanent part of an large inode on the disk ++ */ ++struct ext2_inode_large { ++ __u16 i_mode; /* File mode */ ++ __u16 i_uid; /* Low 16 bits of Owner Uid */ ++ __u32 i_size; /* Size in bytes */ ++ __u32 i_atime; /* Access time */ ++ __u32 i_ctime; /* Inode Change time */ ++ __u32 i_mtime; /* Modification time */ ++ __u32 i_dtime; /* Deletion Time */ ++ __u16 i_gid; /* Low 16 bits of Group Id */ ++ __u16 i_links_count; /* Links count */ ++ __u32 i_blocks; /* Blocks count */ ++ __u32 i_flags; /* File flags */ ++ union { ++ struct { ++ __u32 l_i_version; /* was l_i_reserved1 */ ++ } linux1; ++ struct { ++ __u32 h_i_translator; ++ } hurd1; ++ } osd1; /* OS dependent 1 */ ++ __u32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */ ++ __u32 i_generation; /* File version (for NFS) */ ++ __u32 i_file_acl; /* File ACL */ ++ __u32 i_size_high; /* Formerly i_dir_acl, directory ACL */ ++ __u32 i_faddr; /* Fragment address */ ++ union { ++ struct { ++ __u16 l_i_blocks_hi; ++ __u16 l_i_file_acl_high; ++ __u16 l_i_uid_high; /* these 2 fields */ ++ __u16 l_i_gid_high; /* were reserved2[0] */ ++ __u16 l_i_checksum_lo; /* crc32c(uuid+inum+inode) */ ++ __u16 l_i_reserved; ++ } linux2; ++ struct { ++ __u8 h_i_frag; /* Fragment number */ ++ __u8 h_i_fsize; /* Fragment size */ ++ __u16 h_i_mode_high; ++ __u16 h_i_uid_high; ++ __u16 h_i_gid_high; ++ __u32 h_i_author; ++ } hurd2; ++ } osd2; /* OS dependent 2 */ ++ __u16 i_extra_isize; ++ __u16 i_checksum_hi; /* crc32c(uuid+inum+inode) */ ++ __u32 i_ctime_extra; /* extra Change time (nsec << 2 | epoch) */ ++ __u32 i_mtime_extra; /* extra Modification time (nsec << 2 | epoch) */ ++ __u32 i_atime_extra; /* extra Access time (nsec << 2 | epoch) */ ++ __u32 i_crtime; /* File creation time */ ++ __u32 i_crtime_extra; /* extra File creation time (nsec << 2 | epoch)*/ ++ __u32 i_version_hi; /* high 32 bits for 64-bit version */ ++}; ++ ++#define i_dir_acl i_size_high ++ ++#if defined(__KERNEL__) || defined(__linux__) ++#define i_reserved1 osd1.linux1.l_i_reserved1 ++#define i_frag osd2.linux2.l_i_frag ++#define i_fsize osd2.linux2.l_i_fsize ++#define i_uid_low i_uid ++#define i_gid_low i_gid ++#define i_uid_high osd2.linux2.l_i_uid_high ++#define i_gid_high osd2.linux2.l_i_gid_high ++#else ++#if defined(__GNU__) ++ ++#define i_translator osd1.hurd1.h_i_translator ++#define i_frag osd2.hurd2.h_i_frag; ++#define i_fsize osd2.hurd2.h_i_fsize; ++#define i_uid_high osd2.hurd2.h_i_uid_high ++#define i_gid_high osd2.hurd2.h_i_gid_high ++#define i_author osd2.hurd2.h_i_author ++ ++#endif /* __GNU__ */ ++#endif /* defined(__KERNEL__) || defined(__linux__) */ ++ ++#define inode_uid(inode) ((inode).i_uid | (inode).osd2.linux2.l_i_uid_high << 16) ++#define inode_gid(inode) ((inode).i_gid | (inode).osd2.linux2.l_i_gid_high << 16) ++#define ext2fs_set_i_uid_high(inode,x) ((inode).osd2.linux2.l_i_uid_high = (x)) ++#define ext2fs_set_i_gid_high(inode,x) ((inode).osd2.linux2.l_i_gid_high = (x)) ++ ++/* ++ * File system states ++ */ ++#define EXT2_VALID_FS 0x0001 /* Unmounted cleanly */ ++#define EXT2_ERROR_FS 0x0002 /* Errors detected */ ++#define EXT3_ORPHAN_FS 0x0004 /* Orphans being recovered */ ++ ++/* ++ * Misc. filesystem flags ++ */ ++#define EXT2_FLAGS_SIGNED_HASH 0x0001 /* Signed dirhash in use */ ++#define EXT2_FLAGS_UNSIGNED_HASH 0x0002 /* Unsigned dirhash in use */ ++#define EXT2_FLAGS_TEST_FILESYS 0x0004 /* OK for use on development code */ ++#define EXT2_FLAGS_IS_SNAPSHOT 0x0010 /* This is a snapshot image */ ++#define EXT2_FLAGS_FIX_SNAPSHOT 0x0020 /* Snapshot inodes corrupted */ ++#define EXT2_FLAGS_FIX_EXCLUDE 0x0040 /* Exclude bitmaps corrupted */ ++ ++/* ++ * Mount flags ++ */ ++#define EXT2_MOUNT_CHECK 0x0001 /* Do mount-time checks */ ++#define EXT2_MOUNT_GRPID 0x0004 /* Create files with directory's group */ ++#define EXT2_MOUNT_DEBUG 0x0008 /* Some debugging messages */ ++#define EXT2_MOUNT_ERRORS_CONT 0x0010 /* Continue on errors */ ++#define EXT2_MOUNT_ERRORS_RO 0x0020 /* Remount fs ro on errors */ ++#define EXT2_MOUNT_ERRORS_PANIC 0x0040 /* Panic on errors */ ++#define EXT2_MOUNT_MINIX_DF 0x0080 /* Mimics the Minix statfs */ ++#define EXT2_MOUNT_NO_UID32 0x0200 /* Disable 32-bit UIDs */ ++ ++#define clear_opt(o, opt) o &= ~EXT2_MOUNT_##opt ++#define set_opt(o, opt) o |= EXT2_MOUNT_##opt ++#define test_opt(sb, opt) (EXT2_SB(sb)->s_mount_opt & \ ++ EXT2_MOUNT_##opt) ++/* ++ * Maximal mount counts between two filesystem checks ++ */ ++#define EXT2_DFL_MAX_MNT_COUNT 20 /* Allow 20 mounts */ ++#define EXT2_DFL_CHECKINTERVAL 0 /* Don't use interval check */ ++ ++/* ++ * Behaviour when detecting errors ++ */ ++#define EXT2_ERRORS_CONTINUE 1 /* Continue execution */ ++#define EXT2_ERRORS_RO 2 /* Remount fs read-only */ ++#define EXT2_ERRORS_PANIC 3 /* Panic */ ++#define EXT2_ERRORS_DEFAULT EXT2_ERRORS_CONTINUE ++ ++#if (__GNUC__ >= 4) ++#define ext4_offsetof(TYPE,MEMBER) __builtin_offsetof(TYPE,MEMBER) ++#else ++#define ext4_offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) ++#endif ++ ++/* ++ * Structure of the super block ++ */ ++struct ext2_super_block { ++ __u32 s_inodes_count; /* Inodes count */ ++ __u32 s_blocks_count; /* Blocks count */ ++ __u32 s_r_blocks_count; /* Reserved blocks count */ ++ __u32 s_free_blocks_count; /* Free blocks count */ ++ __u32 s_free_inodes_count; /* Free inodes count */ ++ __u32 s_first_data_block; /* First Data Block */ ++ __u32 s_log_block_size; /* Block size */ ++ __u32 s_log_cluster_size; /* Allocation cluster size */ ++ __u32 s_blocks_per_group; /* # Blocks per group */ ++ __u32 s_clusters_per_group; /* # Fragments per group */ ++ __u32 s_inodes_per_group; /* # Inodes per group */ ++ __u32 s_mtime; /* Mount time */ ++ __u32 s_wtime; /* Write time */ ++ __u16 s_mnt_count; /* Mount count */ ++ __s16 s_max_mnt_count; /* Maximal mount count */ ++ __u16 s_magic; /* Magic signature */ ++ __u16 s_state; /* File system state */ ++ __u16 s_errors; /* Behaviour when detecting errors */ ++ __u16 s_minor_rev_level; /* minor revision level */ ++ __u32 s_lastcheck; /* time of last check */ ++ __u32 s_checkinterval; /* max. time between checks */ ++ __u32 s_creator_os; /* OS */ ++ __u32 s_rev_level; /* Revision level */ ++ __u16 s_def_resuid; /* Default uid for reserved blocks */ ++ __u16 s_def_resgid; /* Default gid for reserved blocks */ ++ /* ++ * These fields are for EXT2_DYNAMIC_REV superblocks only. ++ * ++ * Note: the difference between the compatible feature set and ++ * the incompatible feature set is that if there is a bit set ++ * in the incompatible feature set that the kernel doesn't ++ * know about, it should refuse to mount the filesystem. ++ * ++ * e2fsck's requirements are more strict; if it doesn't know ++ * about a feature in either the compatible or incompatible ++ * feature set, it must abort and not try to meddle with ++ * things it doesn't understand... ++ */ ++ __u32 s_first_ino; /* First non-reserved inode */ ++ __u16 s_inode_size; /* size of inode structure */ ++ __u16 s_block_group_nr; /* block group # of this superblock */ ++ __u32 s_feature_compat; /* compatible feature set */ ++ __u32 s_feature_incompat; /* incompatible feature set */ ++ __u32 s_feature_ro_compat; /* readonly-compatible feature set */ ++ __u8 s_uuid[16]; /* 128-bit uuid for volume */ ++ char s_volume_name[16]; /* volume name */ ++ char s_last_mounted[64]; /* directory where last mounted */ ++ __u32 s_algorithm_usage_bitmap; /* For compression */ ++ /* ++ * Performance hints. Directory preallocation should only ++ * happen if the EXT2_FEATURE_COMPAT_DIR_PREALLOC flag is on. ++ */ ++ __u8 s_prealloc_blocks; /* Nr of blocks to try to preallocate*/ ++ __u8 s_prealloc_dir_blocks; /* Nr to preallocate for dirs */ ++ __u16 s_reserved_gdt_blocks; /* Per group table for online growth */ ++ /* ++ * Journaling support valid if EXT2_FEATURE_COMPAT_HAS_JOURNAL set. ++ */ ++ __u8 s_journal_uuid[16]; /* uuid of journal superblock */ ++ __u32 s_journal_inum; /* inode number of journal file */ ++ __u32 s_journal_dev; /* device number of journal file */ ++ __u32 s_last_orphan; /* start of list of inodes to delete */ ++ __u32 s_hash_seed[4]; /* HTREE hash seed */ ++ __u8 s_def_hash_version; /* Default hash version to use */ ++ __u8 s_jnl_backup_type; /* Default type of journal backup */ ++ __u16 s_desc_size; /* Group desc. size: INCOMPAT_64BIT */ ++ __u32 s_default_mount_opts; ++ __u32 s_first_meta_bg; /* First metablock group */ ++ __u32 s_mkfs_time; /* When the filesystem was created */ ++ __u32 s_jnl_blocks[17]; /* Backup of the journal inode */ ++ __u32 s_blocks_count_hi; /* Blocks count high 32bits */ ++ __u32 s_r_blocks_count_hi; /* Reserved blocks count high 32 bits*/ ++ __u32 s_free_blocks_hi; /* Free blocks count */ ++ __u16 s_min_extra_isize; /* All inodes have at least # bytes */ ++ __u16 s_want_extra_isize; /* New inodes should reserve # bytes */ ++ __u32 s_flags; /* Miscellaneous flags */ ++ __u16 s_raid_stride; /* RAID stride */ ++ __u16 s_mmp_update_interval; /* # seconds to wait in MMP checking */ ++ __u64 s_mmp_block; /* Block for multi-mount protection */ ++ __u32 s_raid_stripe_width; /* blocks on all data disks (N*stride)*/ ++ __u8 s_log_groups_per_flex; /* FLEX_BG group size */ ++ __u8 s_reserved_char_pad; ++ __u16 s_reserved_pad; /* Padding to next 32bits */ ++ __u64 s_kbytes_written; /* nr of lifetime kilobytes written */ ++ __u32 s_snapshot_inum; /* Inode number of active snapshot */ ++ __u32 s_snapshot_id; /* sequential ID of active snapshot */ ++ __u64 s_snapshot_r_blocks_count; /* reserved blocks for active ++ snapshot's future use */ ++ __u32 s_snapshot_list; /* inode number of the head of the on-disk snapshot list */ ++#define EXT4_S_ERR_START ext4_offsetof(struct ext2_super_block, s_error_count) ++ __u32 s_error_count; /* number of fs errors */ ++ __u32 s_first_error_time; /* first time an error happened */ ++ __u32 s_first_error_ino; /* inode involved in first error */ ++ __u64 s_first_error_block; /* block involved of first error */ ++ __u8 s_first_error_func[32]; /* function where the error happened */ ++ __u32 s_first_error_line; /* line number where error happened */ ++ __u32 s_last_error_time; /* most recent time of an error */ ++ __u32 s_last_error_ino; /* inode involved in last error */ ++ __u32 s_last_error_line; /* line number where error happened */ ++ __u64 s_last_error_block; /* block involved of last error */ ++ __u8 s_last_error_func[32]; /* function where the error happened */ ++#define EXT4_S_ERR_END ext4_offsetof(struct ext2_super_block, s_mount_opts) ++ __u8 s_mount_opts[64]; ++ __u32 s_usr_quota_inum; /* inode number of user quota file */ ++ __u32 s_grp_quota_inum; /* inode number of group quota file */ ++ __u32 s_overhead_blocks; /* overhead blocks/clusters in fs */ ++ __u32 s_reserved[108]; /* Padding to the end of the block */ ++ __u32 s_checksum; /* crc32c(superblock) */ ++}; ++ ++#define EXT4_S_ERR_LEN (EXT4_S_ERR_END - EXT4_S_ERR_START) ++ ++/* ++ * Codes for operating systems ++ */ ++#define EXT2_OS_LINUX 0 ++#define EXT2_OS_HURD 1 ++#define EXT2_OBSO_OS_MASIX 2 ++#define EXT2_OS_FREEBSD 3 ++#define EXT2_OS_LITES 4 ++ ++/* ++ * Revision levels ++ */ ++#define EXT2_GOOD_OLD_REV 0 /* The good old (original) format */ ++#define EXT2_DYNAMIC_REV 1 /* V2 format w/ dynamic inode sizes */ ++ ++#define EXT2_CURRENT_REV EXT2_GOOD_OLD_REV ++#define EXT2_MAX_SUPP_REV EXT2_DYNAMIC_REV ++ ++#define EXT2_GOOD_OLD_INODE_SIZE 128 ++ ++/* ++ * Journal inode backup types ++ */ ++#define EXT3_JNL_BACKUP_BLOCKS 1 ++ ++/* ++ * Feature set definitions ++ */ ++ ++#define EXT2_HAS_COMPAT_FEATURE(sb,mask) \ ++ ( EXT2_SB(sb)->s_feature_compat & (mask) ) ++#define EXT2_HAS_RO_COMPAT_FEATURE(sb,mask) \ ++ ( EXT2_SB(sb)->s_feature_ro_compat & (mask) ) ++#define EXT2_HAS_INCOMPAT_FEATURE(sb,mask) \ ++ ( EXT2_SB(sb)->s_feature_incompat & (mask) ) ++ ++#define EXT2_FEATURE_COMPAT_DIR_PREALLOC 0x0001 ++#define EXT2_FEATURE_COMPAT_IMAGIC_INODES 0x0002 ++#define EXT3_FEATURE_COMPAT_HAS_JOURNAL 0x0004 ++#define EXT2_FEATURE_COMPAT_EXT_ATTR 0x0008 ++#define EXT2_FEATURE_COMPAT_RESIZE_INODE 0x0010 ++#define EXT2_FEATURE_COMPAT_DIR_INDEX 0x0020 ++#define EXT2_FEATURE_COMPAT_LAZY_BG 0x0040 ++/* #define EXT2_FEATURE_COMPAT_EXCLUDE_INODE 0x0080 not used, legacy */ ++#define EXT2_FEATURE_COMPAT_EXCLUDE_BITMAP 0x0100 ++ ++ ++#define EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER 0x0001 ++#define EXT2_FEATURE_RO_COMPAT_LARGE_FILE 0x0002 ++/* #define EXT2_FEATURE_RO_COMPAT_BTREE_DIR 0x0004 not used */ ++#define EXT4_FEATURE_RO_COMPAT_HUGE_FILE 0x0008 ++#define EXT4_FEATURE_RO_COMPAT_GDT_CSUM 0x0010 ++#define EXT4_FEATURE_RO_COMPAT_DIR_NLINK 0x0020 ++#define EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE 0x0040 ++#define EXT4_FEATURE_RO_COMPAT_HAS_SNAPSHOT 0x0080 ++#define EXT4_FEATURE_RO_COMPAT_QUOTA 0x0100 ++#define EXT4_FEATURE_RO_COMPAT_BIGALLOC 0x0200 ++#define EXT4_FEATURE_RO_COMPAT_METADATA_CSUM 0x0400 ++#define EXT4_FEATURE_RO_COMPAT_REPLICA 0x0800 ++ ++#define EXT2_FEATURE_INCOMPAT_COMPRESSION 0x0001 ++#define EXT2_FEATURE_INCOMPAT_FILETYPE 0x0002 ++#define EXT3_FEATURE_INCOMPAT_RECOVER 0x0004 /* Needs recovery */ ++#define EXT3_FEATURE_INCOMPAT_JOURNAL_DEV 0x0008 /* Journal device */ ++#define EXT2_FEATURE_INCOMPAT_META_BG 0x0010 ++#define EXT3_FEATURE_INCOMPAT_EXTENTS 0x0040 ++#define EXT4_FEATURE_INCOMPAT_64BIT 0x0080 ++#define EXT4_FEATURE_INCOMPAT_MMP 0x0100 ++#define EXT4_FEATURE_INCOMPAT_FLEX_BG 0x0200 ++#define EXT4_FEATURE_INCOMPAT_EA_INODE 0x0400 ++#define EXT4_FEATURE_INCOMPAT_DIRDATA 0x1000 ++ ++#define EXT2_FEATURE_COMPAT_SUPP 0 ++#define EXT2_FEATURE_INCOMPAT_SUPP (EXT2_FEATURE_INCOMPAT_FILETYPE| \ ++ EXT4_FEATURE_INCOMPAT_MMP) ++#define EXT2_FEATURE_RO_COMPAT_SUPP (EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER| \ ++ EXT2_FEATURE_RO_COMPAT_LARGE_FILE| \ ++ EXT4_FEATURE_RO_COMPAT_DIR_NLINK| \ ++ EXT2_FEATURE_RO_COMPAT_BTREE_DIR) ++ ++/* ++ * Default values for user and/or group using reserved blocks ++ */ ++#define EXT2_DEF_RESUID 0 ++#define EXT2_DEF_RESGID 0 ++ ++/* ++ * Default mount options ++ */ ++#define EXT2_DEFM_DEBUG 0x0001 ++#define EXT2_DEFM_BSDGROUPS 0x0002 ++#define EXT2_DEFM_XATTR_USER 0x0004 ++#define EXT2_DEFM_ACL 0x0008 ++#define EXT2_DEFM_UID16 0x0010 ++#define EXT3_DEFM_JMODE 0x0060 ++#define EXT3_DEFM_JMODE_DATA 0x0020 ++#define EXT3_DEFM_JMODE_ORDERED 0x0040 ++#define EXT3_DEFM_JMODE_WBACK 0x0060 ++#define EXT4_DEFM_NOBARRIER 0x0100 ++#define EXT4_DEFM_BLOCK_VALIDITY 0x0200 ++#define EXT4_DEFM_DISCARD 0x0400 ++#define EXT4_DEFM_NODELALLOC 0x0800 ++ ++/* ++ * Structure of a directory entry ++ */ ++#define EXT2_NAME_LEN 255 ++ ++struct ext2_dir_entry { ++ __u32 inode; /* Inode number */ ++ __u16 rec_len; /* Directory entry length */ ++ __u16 name_len; /* Name length */ ++ char name[EXT2_NAME_LEN]; /* File name */ ++}; ++ ++/* ++ * The new version of the directory entry. Since EXT2 structures are ++ * stored in intel byte order, and the name_len field could never be ++ * bigger than 255 chars, it's safe to reclaim the extra byte for the ++ * file_type field. ++ */ ++struct ext2_dir_entry_2 { ++ __u32 inode; /* Inode number */ ++ __u16 rec_len; /* Directory entry length */ ++ __u8 name_len; /* Name length */ ++ __u8 file_type; ++ char name[EXT2_NAME_LEN]; /* File name */ ++}; ++ ++/* ++ * Ext2 directory file types. Only the low 3 bits are used. The ++ * other bits are reserved for now. ++ */ ++#define EXT2_FT_UNKNOWN 0 ++#define EXT2_FT_REG_FILE 1 ++#define EXT2_FT_DIR 2 ++#define EXT2_FT_CHRDEV 3 ++#define EXT2_FT_BLKDEV 4 ++#define EXT2_FT_FIFO 5 ++#define EXT2_FT_SOCK 6 ++#define EXT2_FT_SYMLINK 7 ++ ++#define EXT2_FT_MAX 8 ++ ++/* ++ * EXT2_DIR_PAD defines the directory entries boundaries ++ * ++ * NOTE: It must be a multiple of 4 ++ */ ++#define EXT2_DIR_PAD 4 ++#define EXT2_DIR_ROUND (EXT2_DIR_PAD - 1) ++#define EXT2_DIR_REC_LEN(name_len) (((name_len) + 8 + EXT2_DIR_ROUND) & \ ++ ~EXT2_DIR_ROUND) ++ ++/* ++ * This structure is used for multiple mount protection. It is written ++ * into the block number saved in the s_mmp_block field in the superblock. ++ * Programs that check MMP should assume that if SEQ_FSCK (or any unknown ++ * code above SEQ_MAX) is present then it is NOT safe to use the filesystem, ++ * regardless of how old the timestamp is. ++ * ++ * The timestamp in the MMP structure will be updated by e2fsck at some ++ * arbitary intervals (start of passes, after every few groups of inodes ++ * in pass1 and pass1b). There is no guarantee that e2fsck is updating ++ * the MMP block in a timely manner, and the updates it does are purely ++ * for the convenience of the sysadmin and not for automatic validation. ++ * ++ * Note: Only the mmp_seq value is used to determine whether the MMP block ++ * is being updated. The mmp_time, mmp_nodename, and mmp_bdevname ++ * fields are only for informational purposes for the administrator, ++ * due to clock skew between nodes and hostname HA service takeover. ++ */ ++#define EXT4_MMP_MAGIC 0x004D4D50U /* ASCII for MMP */ ++#define EXT4_MMP_SEQ_CLEAN 0xFF4D4D50U /* mmp_seq value for clean unmount */ ++#define EXT4_MMP_SEQ_FSCK 0xE24D4D50U /* mmp_seq value when being fscked */ ++#define EXT4_MMP_SEQ_MAX 0xE24D4D4FU /* maximum valid mmp_seq value */ ++ ++struct mmp_struct { ++ __u32 mmp_magic; /* Magic number for MMP */ ++ __u32 mmp_seq; /* Sequence no. updated periodically */ ++ __u64 mmp_time; /* Time last updated */ ++ char mmp_nodename[64]; /* Node which last updated MMP block */ ++ char mmp_bdevname[32]; /* Bdev which last updated MMP block */ ++ __u16 mmp_check_interval; /* Changed mmp_check_interval */ ++ __u16 mmp_pad1; ++ __u32 mmp_pad2[227]; ++}; ++ ++/* ++ * Default interval for MMP update in seconds. ++ */ ++#define EXT4_MMP_UPDATE_INTERVAL 5 ++ ++/* ++ * Maximum interval for MMP update in seconds. ++ */ ++#define EXT4_MMP_MAX_UPDATE_INTERVAL 300 ++ ++/* ++ * Minimum interval for MMP checking in seconds. ++ */ ++#define EXT4_MMP_MIN_CHECK_INTERVAL 5 ++ ++#endif /* _EXT2FS_EXT2_FS_H */ +Index: syslinux-4.03/libinstaller/linuxioctl.h +=================================================================== +--- syslinux-4.03.orig/libinstaller/linuxioctl.h ++++ syslinux-4.03/libinstaller/linuxioctl.h +@@ -9,17 +9,33 @@ + + #include <sys/ioctl.h> + ++#ifdef __linux__ ++ + #define statfs _kernel_statfs /* HACK to deal with broken 2.4 distros */ + + #include <linux/fd.h> /* Floppy geometry */ + #include <linux/hdreg.h> /* Hard disk geometry */ + +-#include <linux/fs.h> /* FIGETBSZ, FIBMAP, FS_IOC_FIEMAP */ ++#include <linux/fs.h> /* FIGETBSZ, FIBMAP, FS_IOC_* */ + #include <linux/msdos_fs.h> /* FAT_IOCTL_SET_ATTRIBUTES */ + + #undef SECTOR_SIZE /* Defined in msdos_fs.h for no good reason */ + #undef SECTOR_BITS +-#include <linux/ext2_fs.h> /* EXT2_IOC_* */ ++ ++#ifndef FS_IOC_GETFLAGS ++/* Old kernel headers, these were once ext2-specific... */ ++# include <linux/ext2_fs.h> /* EXT2_IOC_* */ ++ ++# define FS_IOC_GETFLAGS EXT2_IOC_GETFLAGS ++# define FS_IOC_SETFLAGS EXT2_IOC_SETFLAGS ++ ++# define FS_IMMUTABLE_FL EXT2_IMMUTABLE_FL ++ ++#else ++ ++# include <ext2fs/ext2_fs.h> ++ ++#endif + + #ifndef FAT_IOCTL_GET_ATTRIBUTES + # define FAT_IOCTL_GET_ATTRIBUTES _IOR('r', 0x10, __u32) +@@ -37,11 +53,13 @@ + + #undef statfs + +-#if defined(__linux__) && !defined(BLKGETSIZE64) ++#ifndef BLKGETSIZE64 + /* This takes a u64, but the size field says size_t. Someone screwed big. */ + # define BLKGETSIZE64 _IOR(0x12,114,size_t) + #endif + + #include <linux/loop.h> + ++#endif /* __linux__ */ ++ + #endif /* LIBINSTALLER_LINUXIOCTL_H */ +Index: syslinux-4.03/libinstaller/syslxcom.c +=================================================================== +--- syslinux-4.03.orig/libinstaller/syslxcom.c ++++ syslinux-4.03/libinstaller/syslxcom.c +@@ -121,9 +121,9 @@ void clear_attributes(int fd) + { + int flags; + +- if (!ioctl(fd, EXT2_IOC_GETFLAGS, &flags)) { +- flags &= ~EXT2_IMMUTABLE_FL; +- ioctl(fd, EXT2_IOC_SETFLAGS, &flags); ++ if (!ioctl(fd, FS_IOC_GETFLAGS, &flags)) { ++ flags &= ~FS_IMMUTABLE_FL; ++ ioctl(fd, FS_IOC_SETFLAGS, &flags); + } + break; + } +@@ -151,9 +151,9 @@ void set_attributes(int fd) + { + int flags; + +- if (st.st_uid == 0 && !ioctl(fd, EXT2_IOC_GETFLAGS, &flags)) { +- flags |= EXT2_IMMUTABLE_FL; +- ioctl(fd, EXT2_IOC_SETFLAGS, &flags); ++ if (st.st_uid == 0 && !ioctl(fd, FS_IOC_GETFLAGS, &flags)) { ++ flags |= FS_IMMUTABLE_FL; ++ ioctl(fd, FS_IOC_SETFLAGS, &flags); + } + break; + } diff --git a/meta/recipes-devtools/syslinux/syslinux_4.03.bb b/meta/recipes-devtools/syslinux/syslinux_4.03.bb index e76fe1faf8..a3eb5668d1 100644 --- a/meta/recipes-devtools/syslinux/syslinux_4.03.bb +++ b/meta/recipes-devtools/syslinux/syslinux_4.03.bb @@ -7,10 +7,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \ # If you really want to run syslinux, you need mtools. We just want the # ldlinux.* stuff for now, so skip mtools-native DEPENDS = "nasm-native" -PR = "r2" +PR = "r3" SRC_URI = "${KERNELORG_MIRROR}/linux/utils/boot/syslinux/syslinux-${PV}.tar.bz2 \ - file://cross-build.patch" + file://cross-build.patch \ + file://libinstaller-Avoid-using-linux-ext2_fs.h.patch" SRC_URI[md5sum] = "a7ca38a0a5786b6efae8fb01a1ae8070" SRC_URI[sha256sum] = "c65567e324f9d1f7f794ae8f9578a0292bbd47d7b8d895a004d2f0152d0bda38" diff --git a/meta/recipes-devtools/unfs-server/unfs-server-2.1+2.2beta47/023-no-rpc-register.patch b/meta/recipes-devtools/unfs-server/unfs-server-2.1+2.2beta47/023-no-rpc-register.patch new file mode 100644 index 0000000000..50f23fcc6c --- /dev/null +++ b/meta/recipes-devtools/unfs-server/unfs-server-2.1+2.2beta47/023-no-rpc-register.patch @@ -0,0 +1,34 @@ +Upstream-Status: Inappropriate [other] +Upstream is not making further releases of this software. + +Signed-off-by: Jason Wessel <jason.wessel@windriver.com> + +# Allow user mode NFS to work without rpcbind / portmap +# Patch origin: Wind River + +--- + rpcmisc.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/rpcmisc.c ++++ b/rpcmisc.c +@@ -91,7 +91,8 @@ not_inetd: + if (transp == NULL) + Dprintf(L_FATAL, "cannot create udp service."); + for (i = 0; (vers = verstbl[i]) != 0; i++) { +- if (!svc_register(transp, prog, vers, dispatch, IPPROTO_UDP)) { ++ if (!(svc_register(transp, prog, vers, dispatch, IPPROTO_UDP) || ++ svc_register(transp, prog, vers, dispatch, 0))) { + Dprintf(L_FATAL, + "unable to register (%s, %d, udp).", + name, vers); +@@ -110,7 +111,8 @@ not_inetd: + transp->xp_ops->xp_recv = auth_rendevouser; + #endif + for (i = 0; (vers = verstbl[i]) != 0; i++) { +- if (!svc_register(transp, prog, vers, dispatch, IPPROTO_TCP)) { ++ if (!(svc_register(transp, prog, vers, dispatch, IPPROTO_TCP) || ++ svc_register(transp, prog, vers, dispatch, 0))) { + Dprintf(L_FATAL, + "unable to register (%s, %d, tcp).", + name, vers); diff --git a/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb b/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb index 8ed2e33f95..29c7052056 100644 --- a/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb +++ b/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb @@ -7,7 +7,7 @@ RDEPENDS_${PN} = "pseudo" RDEPENDS_${PN}_virtclass-native = "pseudo-native" RDEPENDS_${PN}_virtclass-nativesdk = "pseudo-nativesdk" BASEPV = "2.2beta47" -PR = "r0" +PR = "r1" SRC_URI = "ftp://linux.mathematik.tu-darmstadt.de/pub/linux/oldstuff/people/okir/nfs-server-${BASEPV}.tar.gz \ file://001-2.2b47-2.2b51.patch \ @@ -32,6 +32,7 @@ SRC_URI = "ftp://linux.mathematik.tu-darmstadt.de/pub/linux/oldstuff/people/okir file://020-undefined-chmod-fix.patch \ file://021-nolibwrap.patch \ file://022-add-close-on-exec-descriptors.patch \ + file://023-no-rpc-register.patch \ " SRC_URI[md5sum] = "79a29fe9f79b2f3241d4915767b8c511" diff --git a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc b/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc deleted file mode 100644 index c881ae0219..0000000000 --- a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc +++ /dev/null @@ -1,43 +0,0 @@ -SUMMARY = "Manage alternatives" -DESCRIPTION = "update-alternatives creates, removes, maintains and displays information about the symbolic links \ -comprising the Debian alternatives system. The Debian alternatives system attempts solve the problem of several \ -programs fulfilling the same or similar functions and how they can be installed onto a single system at the same \ -time." -LICENSE = "GPL" -SECTION = "base" -SRC_URI = "${DEBIAN_MIRROR}/main/d/dpkg/dpkg_${PV}.tar.bz2" -S = "${WORKDIR}/dpkg-${PV}" -PACKAGE_ARCH = "all" -INC_PR = "r3" - -inherit gettext - -do_patch () { - cat ${S}/scripts/update-alternatives.pl | \ - sed -n -e ' - /^\$admindir=.*staging/{ - x - s/^.*$/$D=$ENV{"D"} || ""\;/; - p; - x; - s,^\$admindir=.*staging.*$,$admindir="$D${localstatedir}/lib/dpkg"\;,; - }; - s,^\$altdir=.*$,$altdir="$D${sysconfdir}/alternatives"\;,; - p;' > ${S}/scripts/update-alternatives -} - -do_install () { - install -d ${D}${sbindir} \ - ${D}${localstatedir}/lib/dpkg/alternatives \ - ${D}${sysconfdir}/alternatives - - install -m 0755 scripts/update-alternatives ${D}${sbindir}/update-alternatives -} - -PROVIDES += "virtual/update-alternatives" -RPROVIDES_${PN} += "update-alternatives" -EXTRA_RDEPENDS = "perl dpkg" -EXTRA_RDEPENDS_virtclass-native = "" -RDEPENDS_${PN} += "${EXTRA_RDEPENDS}" - -BBCLASSEXTEND = "native" diff --git a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg_1.16.0.3.bb b/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg_1.16.0.3.bb deleted file mode 100644 index f2931773b7..0000000000 --- a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg_1.16.0.3.bb +++ /dev/null @@ -1,8 +0,0 @@ -require update-alternatives-dpkg.inc - -PR = "${INC_PR}.0" - -LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" - -SRC_URI[md5sum] = "0266b06ef9da8278cea008d21e17e5f6" -SRC_URI[sha256sum] = "69669720020e67629d70aa5325e3c20c05cae7a9fc2d8abd442672c7b29e31d3" diff --git a/meta/recipes-extended/at/at_3.1.12.bb b/meta/recipes-extended/at/at_3.1.12.bb index 30fdb68f36..f2017b77f9 100644 --- a/meta/recipes-extended/at/at_3.1.12.bb +++ b/meta/recipes-extended/at/at_3.1.12.bb @@ -11,7 +11,7 @@ PAM_DEPS = "libpam libpam-runtime pam-plugin-env pam-plugin-limits" RCONFLICTS_${PN} = "atd" RREPLACES_${PN} = "atd" -PR = "r6" +PR = "r7" SRC_URI = "${DEBIAN_MIRROR}/main/a/at/at_${PV}.orig.tar.gz \ file://configure.patch \ @@ -50,6 +50,8 @@ do_install () { install -d ${D}${sysconfdir}/rcS.d install -m 0755 ${WORKDIR}/S99at ${D}${sysconfdir}/init.d/atd ln -sf ../init.d/atd ${D}${sysconfdir}/rcS.d/S99at + cp -r ${D}/usr/doc/at ${D}${docdir}/ + rm -rf ${D}/usr/doc for feature in ${DISTRO_FEATURES}; do if [ "$feature" = "pam" ]; then diff --git a/meta/recipes-extended/bash/bash.inc b/meta/recipes-extended/bash/bash.inc index d55e517de1..876be1e42d 100644 --- a/meta/recipes-extended/bash/bash.inc +++ b/meta/recipes-extended/bash/bash.inc @@ -22,9 +22,12 @@ ALTERNATIVE_PATH = "${base_bindir}/bash" ALTERNATIVE_LINK = "${base_bindir}/sh" ALTERNATIVE_PRIORITY = "100" -do_configure () { - gnu-configize - oe_runconf +export AUTOHEADER = "true" + +do_configure_prepend () { + if [ ! -e acinclude.m4 ]; then + cat aclocal.m4 > acinclude.m4 + fi } pkg_postinst_${PN} () { diff --git a/meta/recipes-extended/bash/bash_3.2.48.bb b/meta/recipes-extended/bash/bash_3.2.48.bb index 1520c4e6ba..f2ba5721c6 100644 --- a/meta/recipes-extended/bash/bash_3.2.48.bb +++ b/meta/recipes-extended/bash/bash_3.2.48.bb @@ -6,7 +6,7 @@ LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=fd5d9bcabd8ed5a54a01ce8d183d592a" DEPENDS = "ncurses" -PR = "r7" +PR = "r8" SRC_URI = "${GNU_MIRROR}/bash/bash-${PV}.tar.gz \ ${GNU_MIRROR}/bash/bash-3.2-patches/bash32-049;apply=yes;striplevel=0 \ @@ -23,9 +23,12 @@ sbindir = "/sbin" EXTRA_OECONF = "--with-ncurses" export CC_FOR_BUILD = "${BUILD_CC}" -do_configure () { - gnu-configize - oe_runconf +export AUTOHEADER = "true" + +do_configure_prepend () { + if [ ! -e acinclude.m4 ]; then + cat aclocal.m4 > acinclude.m4 + fi } pkg_postinst_${PN} () { diff --git a/meta/recipes-extended/cups/cups14.inc b/meta/recipes-extended/cups/cups14.inc index e64f239a6a..48f493d6c7 100644 --- a/meta/recipes-extended/cups/cups14.inc +++ b/meta/recipes-extended/cups/cups14.inc @@ -64,16 +64,24 @@ python do_package_append() { PACKAGES =+ "${PN}-lib ${PN}-libimage" +FILES_${PN} += "${exec_prefix}/lib/cups/backend \ + ${exec_prefix}/lib/cups/cgi-bin \ + ${exec_prefix}/lib/cups/filter \ + ${exec_prefix}/lib/cups/monitor \ + ${exec_prefix}/lib/cups/notifier \ + ${exec_prefix}/lib/cups/daemon \ + " + FILES_${PN}-lib = "${libdir}/libcups.so.*" FILES_${PN}-libimage = "${libdir}/libcupsimage.so.*" -FILES_${PN}-dbg += "${libdir}/cups/backend/.debug \ - ${libdir}/cups/cgi-bin/.debug \ - ${libdir}/cups/filter/.debug \ - ${libdir}/cups/monitor/.debug \ - ${libdir}/cups/notifier/.debug \ - ${libdir}/cups/daemon/.debug \ +FILES_${PN}-dbg += "${exec_prefix}/lib/cups/backend/.debug \ + ${exec_prefix}/lib/cups/cgi-bin/.debug \ + ${exec_prefix}/lib/cups/filter/.debug \ + ${exec_prefix}/lib/cups/monitor/.debug \ + ${exec_prefix}/lib/cups/notifier/.debug \ + ${exec_prefix}/lib/cups/daemon/.debug \ " #package the html for the webgui inside the main packages (~1MB uncompressed) diff --git a/meta/recipes-extended/cups/cups_1.4.6.bb b/meta/recipes-extended/cups/cups_1.4.6.bb index fd20dcceeb..0dc2d4a26b 100644 --- a/meta/recipes-extended/cups/cups_1.4.6.bb +++ b/meta/recipes-extended/cups/cups_1.4.6.bb @@ -1,6 +1,6 @@ require cups14.inc -PR = "r1" +PR = "r2" DEPENDS += "libusb \ ${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}" diff --git a/meta/recipes-extended/ed/ed_0.5.bb b/meta/recipes-extended/ed/ed_0.5.bb index a652332d81..d251e4e390 100644 --- a/meta/recipes-extended/ed/ed_0.5.bb +++ b/meta/recipes-extended/ed/ed_0.5.bb @@ -5,9 +5,17 @@ LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=6ddd5335ef96fb858a138230af773710 \ file://main.c;beginline=1;endline=17;md5=36d4b85e5ae9028e918d1cc775c2475e" -PR = "r1" +PR = "r2" SRC_URI = "http://download.savannah.gnu.org/releases-noredirect/ed/ed-${PV}.tar.bz2" +SRC_URI[md5sum] = "4ee21e9dcc9b5b6012c23038734e1632" +SRC_URI[sha256sum] = "edef2bbde0fbf0d88232782a0eded323f483a0519d6fde9a3b1809056fd35f3e" + inherit autotools +EXTRA_OECONF = "'CC=${CC}' 'CXX=${CXX}' 'CFLAGS=${CFLAGS}' 'CXXFLAGS=${CXXFLAGS}' 'CPPFLAGS=${CPPFLAGS}' 'LDFLAGS=${LDFLAGS}'" + +CONFIGUREOPTS := "${@d.getVar('CONFIGUREOPTS', True).replace('--disable-dependency-tracking', ' ')}" CONFIGUREOPTS := "${@d.getVar('CONFIGUREOPTS', True).replace('--disable-silent-rules', ' ')}" + + diff --git a/meta/recipes-extended/ghostscript/ghostscript/powerpc64/objarch.h b/meta/recipes-extended/ghostscript/ghostscript/powerpc64/objarch.h new file mode 100644 index 0000000000..0d0a16bfa3 --- /dev/null +++ b/meta/recipes-extended/ghostscript/ghostscript/powerpc64/objarch.h @@ -0,0 +1,40 @@ +/* Parameters derived from machine and compiler architecture. */ +/* This file is generated mechanically by genarch.c. */ + + /* ---------------- Scalar alignments ---------------- */ + +#define ARCH_ALIGN_SHORT_MOD 2 +#define ARCH_ALIGN_INT_MOD 4 +#define ARCH_ALIGN_LONG_MOD 8 +#define ARCH_ALIGN_PTR_MOD 8 +#define ARCH_ALIGN_FLOAT_MOD 4 +#define ARCH_ALIGN_DOUBLE_MOD 8 + + /* ---------------- Scalar sizes ---------------- */ + +#define ARCH_LOG2_SIZEOF_CHAR 0 +#define ARCH_LOG2_SIZEOF_SHORT 1 +#define ARCH_LOG2_SIZEOF_INT 2 +#define ARCH_LOG2_SIZEOF_LONG 3 +#define ARCH_LOG2_SIZEOF_LONG_LONG 3 +#define ARCH_SIZEOF_GX_COLOR_INDEX 8 +#define ARCH_SIZEOF_PTR 8 +#define ARCH_SIZEOF_FLOAT 4 +#define ARCH_SIZEOF_DOUBLE 8 +#define ARCH_FLOAT_MANTISSA_BITS 24 +#define ARCH_DOUBLE_MANTISSA_BITS 53 + + /* ---------------- Unsigned max values ---------------- */ + +#define ARCH_MAX_UCHAR ((unsigned char)0xff + (unsigned char)0) +#define ARCH_MAX_USHORT ((unsigned short)0xffff + (unsigned short)0) +#define ARCH_MAX_UINT ((unsigned int)~0 + (unsigned int)0) +#define ARCH_MAX_ULONG ((unsigned long)~0L + (unsigned long)0) + + /* ---------------- Miscellaneous ---------------- */ + +#define ARCH_IS_BIG_ENDIAN 1 +#define ARCH_PTRS_ARE_SIGNED 0 +#define ARCH_FLOATS_ARE_IEEE 1 +#define ARCH_ARITH_RSHIFT 2 +#define ARCH_DIV_NEG_POS_TRUNCATES 1 diff --git a/meta/recipes-extended/ghostscript/ghostscript/powerpc64/soobjarch.h b/meta/recipes-extended/ghostscript/ghostscript/powerpc64/soobjarch.h new file mode 100644 index 0000000000..0d0a16bfa3 --- /dev/null +++ b/meta/recipes-extended/ghostscript/ghostscript/powerpc64/soobjarch.h @@ -0,0 +1,40 @@ +/* Parameters derived from machine and compiler architecture. */ +/* This file is generated mechanically by genarch.c. */ + + /* ---------------- Scalar alignments ---------------- */ + +#define ARCH_ALIGN_SHORT_MOD 2 +#define ARCH_ALIGN_INT_MOD 4 +#define ARCH_ALIGN_LONG_MOD 8 +#define ARCH_ALIGN_PTR_MOD 8 +#define ARCH_ALIGN_FLOAT_MOD 4 +#define ARCH_ALIGN_DOUBLE_MOD 8 + + /* ---------------- Scalar sizes ---------------- */ + +#define ARCH_LOG2_SIZEOF_CHAR 0 +#define ARCH_LOG2_SIZEOF_SHORT 1 +#define ARCH_LOG2_SIZEOF_INT 2 +#define ARCH_LOG2_SIZEOF_LONG 3 +#define ARCH_LOG2_SIZEOF_LONG_LONG 3 +#define ARCH_SIZEOF_GX_COLOR_INDEX 8 +#define ARCH_SIZEOF_PTR 8 +#define ARCH_SIZEOF_FLOAT 4 +#define ARCH_SIZEOF_DOUBLE 8 +#define ARCH_FLOAT_MANTISSA_BITS 24 +#define ARCH_DOUBLE_MANTISSA_BITS 53 + + /* ---------------- Unsigned max values ---------------- */ + +#define ARCH_MAX_UCHAR ((unsigned char)0xff + (unsigned char)0) +#define ARCH_MAX_USHORT ((unsigned short)0xffff + (unsigned short)0) +#define ARCH_MAX_UINT ((unsigned int)~0 + (unsigned int)0) +#define ARCH_MAX_ULONG ((unsigned long)~0L + (unsigned long)0) + + /* ---------------- Miscellaneous ---------------- */ + +#define ARCH_IS_BIG_ENDIAN 1 +#define ARCH_PTRS_ARE_SIGNED 0 +#define ARCH_FLOATS_ARE_IEEE 1 +#define ARCH_ARITH_RSHIFT 2 +#define ARCH_DIV_NEG_POS_TRUNCATES 1 diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb index 9b21c66956..99c4f5cde8 100644 --- a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb +++ b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb @@ -40,6 +40,7 @@ EXTRA_OECONF = "--without-x --with-system-libtiff --without-jbig2dec --without-j # http://bugs.ghostscript.com/show_bug.cgi?id=692443 # http://bugs.ghostscript.com/show_bug.cgi?id=692426 CFLAGS += "-DHAVE_SYS_TIME_H=1" +BUILD_CFLAGS += "-DHAVE_SYS_TIME_H=1" inherit autotools diff --git a/meta/recipes-extended/libzypp/libzypp_git.bb b/meta/recipes-extended/libzypp/libzypp_git.bb index 7d9382a0bf..af60d98774 100644 --- a/meta/recipes-extended/libzypp/libzypp_git.bb +++ b/meta/recipes-extended/libzypp/libzypp_git.bb @@ -11,7 +11,7 @@ DEPENDS = "rpm boost curl libxml2 zlib sat-solver expat openssl udev" S = "${WORKDIR}/git" SRCREV = "15b6c52260bbc52b3d8e585e271b67e10cc7c433" PV = "0.0-git${SRCPV}" -PR = "r15" +PR = "r16" SRC_URI = "git://github.com/openSUSE/libzypp.git;protocol=git \ file://no-doc.patch \ @@ -98,10 +98,10 @@ do_archgen () { esac if [ "${AVOID_CONSTRUCTOR}" != "true" ]; then echo -n " const Arch Arch_${each_arch} " | tr - _ >> zypp/oe-arch.h - echo "(_${each_arch});" >> zypp/oe-arch.h + echo "(_${each_arch});" | tr - _ >> zypp/oe-arch.h else echo -n " const Arch Arch_${each_arch} " | tr - _ >> zypp/oe-arch.h - echo "( IdString ( \"${each_arch}\" ) );" >> zypp/oe-arch.h + echo "( IdString ( \"${each_arch}\" ) );" | tr - _ >> zypp/oe-arch.h fi done echo "#endif /* OE_PROTO */" >> zypp/oe-arch.h @@ -142,7 +142,7 @@ do_archgen () { COMPAT_WITH="${CARCH},${COMPAT} $COMPAT_WITH" done for each_compat in ${COMPAT_WITH} ; do - echo " defCompatibleWith( ${each_compat} );" >> zypp/oe-arch.h + echo " defCompatibleWith( ${each_compat} );" | tr - _ >> zypp/oe-arch.h done echo "#endif /* DEF_COMPAT */" >> zypp/oe-arch.h echo "" >> zypp/oe-arch.h diff --git a/meta/recipes-extended/lsb/lsb_1.4.bb b/meta/recipes-extended/lsb/lsb_1.4.bb index d47201265e..7cecdf21bd 100644 --- a/meta/recipes-extended/lsb/lsb_1.4.bb +++ b/meta/recipes-extended/lsb/lsb_1.4.bb @@ -2,7 +2,7 @@ DESCRIPTION = "LSB support for Poky Linux" SECTION = "console/utils" HOMEPAGE = "http://prdownloads.sourceforge.net/lsb" LICENSE = "GPLv2+" -PR = "r1" +PR = "r2" LIC_FILES_CHKSUM = "file://README;md5=12da544b1a3a5a1795a21160b49471cf" @@ -19,7 +19,7 @@ SRC_URI[sha256sum] = "99321288f8d62e7a1d485b7c6bdccf06766fb8ca603c6195806e4457fd S = ${WORKDIR}/lsb-release-${PV} do_install(){ - oe_runmake install prefix=${D} mandir=${D}/man/ DESTDIR=${D} + oe_runmake install prefix=${D} mandir=${D}/${datadir}/man/ DESTDIR=${D} mkdir -p ${D}/bin mkdir -p ${D}/${baselib} mkdir -p ${D}/etc/lsb-release.d @@ -69,7 +69,9 @@ do_install_append(){ install -m 0755 ${WORKDIR}/init-functions ${D}/${baselib}/lsb if [ "${TARGET_ARCH}" == "x86_64" ];then cd ${D} - ln -sf ${baselib} lib + if [ "${baselib}" != "lib64" ]; then + ln -sf ${baselib} lib64 + fi cd ${D}/${baselib} ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.2 ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3 @@ -82,7 +84,9 @@ do_install_append(){ if [ "${TARGET_ARCH}" == "powerpc64" ];then cd ${D} - ln -sf ${baselib} lib + if [ "${baselib}" != "lib64" ]; then + ln -sf ${baselib} lib64 + fi cd ${D}/${baselib} ln -sf ld64.so.1 ld-lsb-ppc64.so.2 ln -sf ld64.so.1 ld-lsb-ppc64.so.3 diff --git a/meta/recipes-extended/man/man_1.6f.bb b/meta/recipes-extended/man/man_1.6f.bb index d38612be81..c98c920a63 100644 --- a/meta/recipes-extended/man/man_1.6f.bb +++ b/meta/recipes-extended/man/man_1.6f.bb @@ -3,7 +3,7 @@ DESCRIPTION = "A set of documentation tools: man, apropos and whatis" SECTION = "console/utils" HOMEPAGE = "http://primates.ximian.com/~flucifredi/man" LICENSE = "GPLv2" -PR = "r0" +PR = "r1" DEPENDS = "groff less" @@ -61,4 +61,4 @@ do_install_append(){ } -FILES_${PN} += "${datadir}/locale" +FILES_${PN} += "${datadir}/locale ${sysconfdir}/man.conf" diff --git a/meta/recipes-extended/mc/mc_4.7.5.2.bb b/meta/recipes-extended/mc/mc_4.7.5.2.bb index 6b03be7415..59f32ad369 100644 --- a/meta/recipes-extended/mc/mc_4.7.5.2.bb +++ b/meta/recipes-extended/mc/mc_4.7.5.2.bb @@ -6,7 +6,7 @@ SECTION = "console/utils" DEPENDS = "ncurses glib-2.0" RDEPENDS_${PN} = "ncurses-terminfo" -PR = "r1" +PR = "r2" SRC_URI = "http://www.midnight-commander.org/downloads/${BPN}-${PV}.tar.bz2" @@ -18,3 +18,8 @@ inherit autotools gettext EXTRA_OECONF = "--with-screen=ncurses --without-gpm-mouse --without-x --without-samba" FILES_${PN}-dbg += "${libexecdir}/mc/.debug/" + +do_install_append () { + sed -i -e '1s,#!.*perl,#!${bindir}/env perl,' ${D}${libexecdir}/mc/extfs.d/* + +} diff --git a/meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch b/meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch new file mode 100644 index 0000000000..931ecbc16d --- /dev/null +++ b/meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch @@ -0,0 +1,50 @@ +From 19986c721c9ac4b353c8592998d70d0dc8860bfd Mon Sep 17 00:00:00 2001 +From: Milan Broz <mbroz@redhat.com> +Date: Thu, 14 Jul 2011 13:58:36 +1000 +Subject: [PATCH] mdadm: fix build failures (ppc64) + +This patch fixes these build issues: + +super-intel.c: In function 'getinfo_super_imsm_volume': +super-intel.c:2327:4: error: format '%llu' expects argument of type 'long long +unsigned int', but argument 3 has type '__u64' [-Werror=format] + +super-intel.c: In function 'imsm_reshape_super': +super-intel.c:8665:7: error: 'devnum' may be used uninitialized in this function [-Werror=uninitialized] + +Signed-off-by: Milan Broz <mbroz@redhat.com> +Signed-off-by: NeilBrown <neilb@suse.de> +--- + super-intel.c | 9 ++++++--- + 1 files changed, 6 insertions(+), 3 deletions(-) + +diff --git a/super-intel.c b/super-intel.c +index 5ea3b36..70cf993 100644 +--- a/super-intel.c ++++ b/super-intel.c +@@ -2326,7 +2326,9 @@ static void getinfo_super_imsm_volume(struct supertype *st, struct mdinfo *info, + + dprintf("IMSM: General Migration checkpoint : %llu " + "(%llu) -> read reshape progress : %llu\n", +- units, blocks_per_unit, info->reshape_progress); ++ (unsigned long long)units, ++ (unsigned long long)blocks_per_unit, ++ info->reshape_progress); + + used_disks = imsm_num_data_members(dev, 1); + if (used_disks > 0) { +@@ -8661,8 +8663,9 @@ static int imsm_reshape_super(struct supertype *st, long long size, int level, + dprintf("imsm: info: Volume operation\n"); + /* find requested device */ + while (dev) { +- imsm_find_array_minor_by_subdev(dev->index, st->container_dev, &devnum); +- if (devnum == geo.dev_id) ++ if (imsm_find_array_minor_by_subdev( ++ dev->index, st->container_dev, &devnum) == 0 ++ && devnum == geo.dev_id) + break; + dev = dev->next; + } +-- +1.7.6.1 + diff --git a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb index 5d29ae781f..97878edb68 100644 --- a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb +++ b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb @@ -8,9 +8,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \ file://mdmon.c;beginline=4;endline=18;md5=af7d8444d9c4d3e5c7caac0d9d34039d \ file://mdadm.h;beglinlne=4;endline=22;md5=462bc9936ac0d3da110191a3f9994161" -PR = "r0" +PR = "r2" -SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2" +SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2 \ + file://0001-mdadm-fix-build-failures-ppc64.patch \ + " SRC_URI[md5sum] = "12ee2fbf3beddb60601fb7a4c4905651" SRC_URI[sha256sum] = "0d1a04e688b082bc88846e3f524abd50bc782b6ffc06123140f7d358c8f9b906" @@ -29,3 +31,4 @@ do_install() { autotools_do_install } +FILES_${PN} += "${base_libdir}/udev/rules.d/*.rules" diff --git a/meta/recipes-extended/pam/libpam_1.1.4.bb b/meta/recipes-extended/pam/libpam_1.1.4.bb index d6f95b198f..868bffd960 100644 --- a/meta/recipes-extended/pam/libpam_1.1.4.bb +++ b/meta/recipes-extended/pam/libpam_1.1.4.bb @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=ca0395de9a86191a078b8b79302e3083" PR = "r2" -DEPENDS = "bison flex cracklib" +DEPENDS = "bison flex flex-native cracklib" RDEPENDS_${PN}-runtime = "libpam pam-plugin-deny pam-plugin-permit pam-plugin-warn pam-plugin-unix" RDEPENDS_${PN}-xtests = "libpam pam-plugin-access pam-plugin-debug pam-plugin-cracklib pam-plugin-pwhistory \ pam-plugin-succeed-if pam-plugin-time coreutils" diff --git a/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb b/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb index 48e107c8fa..98ca8049cd 100644 --- a/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb +++ b/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb @@ -11,10 +11,8 @@ SRC_URI[sha256sum] = "be63d5cc715d7306e54b41d3c68c3617ca306289cff619a2ca43505e35 S = "${WORKDIR}/Convert-ASN1-${PV}" -inherit cpan +inherit cpan allarch EXTRA_PERLFLAGS = "-I ${STAGING_LIBDIR_NATIVE}/perl-native/perl/${@get_perl_version(d)}" -BBCLASSEXTEND="native" - -PACKAGE_ARCH = "all" +BBCLASSEXTEND = "native" diff --git a/meta/recipes-extended/perl/libtimedate-perl_1.20.bb b/meta/recipes-extended/perl/libtimedate-perl_1.20.bb index c925980d37..67c583691d 100644 --- a/meta/recipes-extended/perl/libtimedate-perl_1.20.bb +++ b/meta/recipes-extended/perl/libtimedate-perl_1.20.bb @@ -10,13 +10,12 @@ SRC_URI = "http://search.cpan.org/CPAN/authors/id/G/GB/GBARR/TimeDate-${PV}.tar. S = "${WORKDIR}/TimeDate-${PV}" -inherit cpan +inherit cpan allarch -BBCLASSEXTEND="native" +BBCLASSEXTEND = "native" RDEPENDS_${PN}_virtclass-native = "" RDEPENDS_${PN} += "perl-module-carp perl-module-exporter perl-module-strict perl-module-time-local" -PACKAGE_ARCH = "all" SRC_URI[md5sum] = "7da7452bce4c684e4238e6d09b390200" SRC_URI[sha256sum] = "f8251a791f6692c69952b4af697c01df93981ad1ab133279d034656a03cd3755" diff --git a/meta/recipes-extended/shadow/files/add_root_cmd_options.patch b/meta/recipes-extended/shadow/files/add_root_cmd_options.patch index c5f2bec56b..5edd3b8744 100644 --- a/meta/recipes-extended/shadow/files/add_root_cmd_options.patch +++ b/meta/recipes-extended/shadow/files/add_root_cmd_options.patch @@ -25,9 +25,18 @@ Workaround is specific to our build system. Signed-off-by: Scott Garman <scott.a.garman@intel.com> +2011-09-29 Fix the parsing of the --root option in gpasswd, useradd, usermod: + +In programs which need to scan the command line in two passes to handle +--root option separately from the rest of the arguments, replace the first +calls to getopt_long with a simple iteration over the argument list since +getopt_long has the bad habit of reordering arguments on the command line. + +Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com> + diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c ---- shadow-4.1.4.3.orig//src/gpasswd.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/gpasswd.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/gpasswd.c 2011-09-29 12:00:45.211000091 +0100 ++++ shadow-4.1.4.3//src/gpasswd.c 2011-09-29 12:09:54.590000090 +0100 @@ -63,6 +63,7 @@ * (/etc/gshadow present) */ static bool is_shadowgrp; @@ -52,7 +61,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c " -r, --remove-password remove the GROUP's password\n" " -R, --restrict restrict access to GROUP to its members\n" " -M, --members USER,... set the list of members of GROUP\n" -@@ -226,6 +229,55 @@ +@@ -226,6 +229,57 @@ } /* @@ -68,23 +77,26 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c + /* + * Parse the command line options. + */ -+ int flag; -+ int option_index = 0; -+ static struct option long_options[] = { -+ {"root", required_argument, NULL, 'Q'}, -+ {NULL, 0, NULL, '\0'} -+ }; ++ int i; ++ char *root; + -+ while ((flag = getopt_long (argc, argv, "a:A:d:gM:Q:rR", long_options, &option_index)) != -1) { -+ switch (flag) { -+ case 'Q': -+ if ('/' != optarg[0]) { ++ for (i = 0; i < argc; i++) { ++ if (!strcmp (argv[i], "--root") || !strcmp (argv[i], "-Q")) { ++ if (i + 1 == argc) { ++ fprintf (stderr, ++ _("%s: option '%s' requires an argument\n"), ++ Prog, argv[i]); ++ exit (E_BAD_ARG); ++ } ++ root = argv[i + 1]; ++ ++ if ('/' != root[0]) { + fprintf (stderr, + _("%s: invalid chroot path '%s'\n"), -+ Prog, optarg); ++ Prog, root); + exit (E_BAD_ARG); + } -+ newroot = optarg; ++ newroot = root; + + if (access (newroot, F_OK) != 0) { + fprintf(stderr, @@ -99,7 +111,6 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c + exit (E_BAD_ARG); + } + break; -+ /* no-op on everything else - they will be hanled by process_flags() */ + } + } +} @@ -108,7 +119,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c * process_flags - process the command line options and arguments */ static void process_flags (int argc, char **argv) -@@ -235,6 +287,7 @@ +@@ -235,6 +289,7 @@ static struct option long_options[] = { {"add", required_argument, NULL, 'a'}, {"delete", required_argument, NULL, 'd'}, @@ -116,7 +127,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c {"remove-password", no_argument, NULL, 'r'}, {"restrict", no_argument, NULL, 'R'}, {"administrators", required_argument, NULL, 'A'}, -@@ -242,7 +295,7 @@ +@@ -242,7 +297,7 @@ {NULL, 0, NULL, '\0'} }; @@ -125,7 +136,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c switch (flag) { case 'a': /* add a user */ aflg = true; -@@ -283,6 +336,9 @@ +@@ -283,6 +338,9 @@ } Mflg = true; break; @@ -135,7 +146,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c case 'r': /* remove group password */ rflg = true; break; -@@ -995,6 +1051,8 @@ +@@ -995,6 +1053,8 @@ setbuf (stdout, NULL); setbuf (stderr, NULL); @@ -145,8 +156,8 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c is_shadowgrp = sgr_file_present (); #endif diff -urN shadow-4.1.4.3.orig//src/groupadd.c shadow-4.1.4.3//src/groupadd.c ---- shadow-4.1.4.3.orig//src/groupadd.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/groupadd.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/groupadd.c 2011-09-29 12:00:45.212000091 +0100 ++++ shadow-4.1.4.3//src/groupadd.c 2011-09-29 11:59:28.386000092 +0100 @@ -76,6 +76,7 @@ static gid_t group_id; static /*@null@*/char *group_passwd; @@ -208,8 +219,8 @@ diff -urN shadow-4.1.4.3.orig//src/groupadd.c shadow-4.1.4.3//src/groupadd.c rflg = true; break; diff -urN shadow-4.1.4.3.orig//src/groupdel.c shadow-4.1.4.3//src/groupdel.c ---- shadow-4.1.4.3.orig//src/groupdel.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/groupdel.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/groupdel.c 2011-09-29 12:00:45.212000091 +0100 ++++ shadow-4.1.4.3//src/groupdel.c 2011-09-29 11:59:28.386000092 +0100 @@ -36,6 +36,7 @@ #include <ctype.h> @@ -340,8 +351,8 @@ diff -urN shadow-4.1.4.3.orig//src/groupdel.c shadow-4.1.4.3//src/groupdel.c #ifdef USE_PAM { diff -urN shadow-4.1.4.3.orig//src/groupmod.c shadow-4.1.4.3//src/groupmod.c ---- shadow-4.1.4.3.orig//src/groupmod.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/groupmod.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/groupmod.c 2011-09-29 12:00:45.212000091 +0100 ++++ shadow-4.1.4.3//src/groupmod.c 2011-09-29 11:59:28.387000092 +0100 @@ -79,6 +79,7 @@ static char *group_passwd; static gid_t group_id; @@ -401,8 +412,8 @@ diff -urN shadow-4.1.4.3.orig//src/groupmod.c shadow-4.1.4.3//src/groupmod.c usage (); } diff -urN shadow-4.1.4.3.orig//src/grpconv.c shadow-4.1.4.3//src/grpconv.c ---- shadow-4.1.4.3.orig//src/grpconv.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/grpconv.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/grpconv.c 2011-09-29 12:00:45.213000091 +0100 ++++ shadow-4.1.4.3//src/grpconv.c 2011-09-29 11:59:28.387000092 +0100 @@ -39,6 +39,7 @@ #include <errno.h> @@ -527,8 +538,8 @@ diff -urN shadow-4.1.4.3.orig//src/grpconv.c shadow-4.1.4.3//src/grpconv.c fprintf (stderr, _("%s: cannot lock %s; try again later.\n"), diff -urN shadow-4.1.4.3.orig//src/grpunconv.c shadow-4.1.4.3//src/grpunconv.c ---- shadow-4.1.4.3.orig//src/grpunconv.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/grpunconv.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/grpunconv.c 2011-09-29 12:00:45.213000091 +0100 ++++ shadow-4.1.4.3//src/grpunconv.c 2011-09-29 11:59:28.387000092 +0100 @@ -43,6 +43,7 @@ #include <stdlib.h> #include <string.h> @@ -653,8 +664,8 @@ diff -urN shadow-4.1.4.3.orig//src/grpunconv.c shadow-4.1.4.3//src/grpunconv.c exit (0); /* no /etc/gshadow, nothing to do */ } diff -urN shadow-4.1.4.3.orig//src/passwd.c shadow-4.1.4.3//src/passwd.c ---- shadow-4.1.4.3.orig//src/passwd.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/passwd.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/passwd.c 2011-09-29 12:00:45.214000091 +0100 ++++ shadow-4.1.4.3//src/passwd.c 2011-09-29 11:59:28.388000092 +0100 @@ -75,6 +75,7 @@ static char *name; /* The name of user whose password is being changed */ static char *myname; /* The current user's name */ @@ -718,8 +729,8 @@ diff -urN shadow-4.1.4.3.orig//src/passwd.c shadow-4.1.4.3//src/passwd.c /* -r repository (files|nis|nisplus) */ /* only "files" supported for now */ diff -urN shadow-4.1.4.3.orig//src/pwconv.c shadow-4.1.4.3//src/pwconv.c ---- shadow-4.1.4.3.orig//src/pwconv.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/pwconv.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/pwconv.c 2011-09-29 12:00:45.214000091 +0100 ++++ shadow-4.1.4.3//src/pwconv.c 2011-09-29 11:59:28.388000092 +0100 @@ -59,6 +59,7 @@ #include <errno.h> @@ -847,8 +858,8 @@ diff -urN shadow-4.1.4.3.orig//src/pwconv.c shadow-4.1.4.3//src/pwconv.c fprintf (stderr, _("%s: cannot lock %s; try again later.\n"), diff -urN shadow-4.1.4.3.orig//src/pwunconv.c shadow-4.1.4.3//src/pwunconv.c ---- shadow-4.1.4.3.orig//src/pwunconv.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/pwunconv.c 2011-06-28 15:12:03.539504372 -0700 +--- shadow-4.1.4.3.orig//src/pwunconv.c 2011-09-29 12:00:45.214000091 +0100 ++++ shadow-4.1.4.3//src/pwunconv.c 2011-09-29 11:59:28.388000092 +0100 @@ -35,6 +35,7 @@ #ident "$Id: pwunconv.c 2852 2009-04-30 21:44:35Z nekral-guest $" @@ -969,8 +980,8 @@ diff -urN shadow-4.1.4.3.orig//src/pwunconv.c shadow-4.1.4.3//src/pwunconv.c /* shadow not installed, do nothing */ exit (0); diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c ---- shadow-4.1.4.3.orig//src/useradd.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/useradd.c 2011-06-28 15:12:14.608787030 -0700 +--- shadow-4.1.4.3.orig//src/useradd.c 2011-09-29 12:00:45.215000091 +0100 ++++ shadow-4.1.4.3//src/useradd.c 2011-09-29 11:59:28.520000092 +0100 @@ -112,6 +112,7 @@ #ifdef WITH_SELINUX static const char *user_selinux = ""; @@ -995,7 +1006,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c (void) fputs (_(" -r, --system create a system account\n"), stderr); (void) fputs (_(" -s, --shell SHELL login shell of the new account\n"), stderr); (void) fputs (_(" -u, --uid UID user ID of the new account\n"), stderr); -@@ -943,6 +946,59 @@ +@@ -943,6 +946,57 @@ } /* @@ -1011,27 +1022,26 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c + /* + * Parse the command line options. + */ -+ int c; -+ static struct option long_options[] = { -+ {"root", required_argument, NULL, 'R'}, -+ {NULL, 0, NULL, '\0'} -+ }; -+ while ((c = getopt_long (argc, argv, -+#ifdef WITH_SELINUX -+ "b:c:d:De:f:g:G:k:K:lmMNop:R:rs:u:UZ:", -+#else -+ "b:c:d:De:f:g:G:k:K:lmMNop:R:rs:u:U", -+#endif -+ long_options, NULL)) != -1) { -+ switch (c) { -+ case 'R': -+ if ('/' != optarg[0]) { ++ int i; ++ char *root; ++ ++ for (i = 0; i < argc; i++) { ++ if (!strcmp (argv[i], "--root") || !strcmp (argv[i], "-R")) { ++ if (i + 1 == argc) { ++ fprintf (stderr, ++ _("%s: option '%s' requires an argument\n"), ++ Prog, argv[i]); ++ exit (E_BAD_ARG); ++ } ++ root = argv[i + 1]; ++ ++ if ('/' != root[0]) { + fprintf (stderr, + _("%s: invalid chroot path '%s'\n"), -+ Prog, optarg); ++ Prog, root); + exit (E_BAD_ARG); + } -+ newroot = optarg; ++ newroot = root; + + if (access (newroot, F_OK) != 0) { + fprintf(stderr, @@ -1046,7 +1056,6 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c + exit (E_BAD_ARG); + } + break; -+ /* no-op on everything else - they will be hanled by process_flags() */ + } + } +} @@ -1055,7 +1064,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c * process_flags - perform command line argument setting * * process_flags() interprets the command line arguments and sets -@@ -978,6 +1034,7 @@ +@@ -978,6 +1032,7 @@ {"no-user-group", no_argument, NULL, 'N'}, {"non-unique", no_argument, NULL, 'o'}, {"password", required_argument, NULL, 'p'}, @@ -1063,7 +1072,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c {"system", no_argument, NULL, 'r'}, {"shell", required_argument, NULL, 's'}, #ifdef WITH_SELINUX -@@ -989,9 +1046,9 @@ +@@ -989,9 +1044,9 @@ }; while ((c = getopt_long (argc, argv, #ifdef WITH_SELINUX @@ -1075,7 +1084,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c #endif long_options, NULL)) != -1) { switch (c) { -@@ -1156,6 +1213,9 @@ +@@ -1156,6 +1211,9 @@ } user_pass = optarg; break; @@ -1085,7 +1094,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c case 'r': rflg = true; break; -@@ -1735,6 +1795,36 @@ +@@ -1735,6 +1793,36 @@ } } #endif @@ -1122,7 +1131,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c /* * create_home - create the user's home directory * -@@ -1748,34 +1838,31 @@ +@@ -1748,34 +1836,31 @@ #ifdef WITH_SELINUX selinux_file_context (user_home); #endif @@ -1175,7 +1184,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c } /* -@@ -1861,6 +1948,7 @@ +@@ -1861,6 +1946,7 @@ */ user_groups[0] = (char *) 0; @@ -1184,8 +1193,8 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c is_shadow_pwd = spw_file_present (); #ifdef SHADOWGRP diff -urN shadow-4.1.4.3.orig//src/userdel.c shadow-4.1.4.3//src/userdel.c ---- shadow-4.1.4.3.orig//src/userdel.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/userdel.c 2011-06-28 15:12:03.549503721 -0700 +--- shadow-4.1.4.3.orig//src/userdel.c 2011-09-29 12:00:45.216000091 +0100 ++++ shadow-4.1.4.3//src/userdel.c 2011-09-29 11:59:28.389000092 +0100 @@ -79,6 +79,7 @@ static char *user_name; static uid_t user_id; @@ -1239,8 +1248,8 @@ diff -urN shadow-4.1.4.3.orig//src/userdel.c shadow-4.1.4.3//src/userdel.c rflg = true; break; diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c ---- shadow-4.1.4.3.orig//src/usermod.c 2011-02-13 09:58:16.000000000 -0800 -+++ shadow-4.1.4.3//src/usermod.c 2011-06-28 15:12:03.549503721 -0700 +--- shadow-4.1.4.3.orig//src/usermod.c 2011-09-29 12:00:45.216000091 +0100 ++++ shadow-4.1.4.3//src/usermod.c 2011-09-29 11:59:28.390000092 +0100 @@ -110,6 +110,7 @@ static long user_newinactive; static long sys_ngroups; @@ -1265,7 +1274,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c " -s, --shell SHELL new login shell for the user account\n" " -u, --uid UID new UID for the user account\n" " -U, --unlock unlock the user account\n" -@@ -802,6 +805,60 @@ +@@ -802,6 +805,58 @@ } /* @@ -1281,28 +1290,27 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c + /* + * Parse the command line options. + */ -+ int c; -+ static struct option long_options[] = { -+ {"root", required_argument, NULL, 'R'}, -+ {NULL, 0, NULL, '\0'} -+ }; -+ while ((c = getopt_long (argc, argv, -+#ifdef WITH_SELINUX -+ "ac:d:e:f:g:G:hl:Lmop:R:s:u:UZ:", -+#else -+ "ac:d:e:f:g:G:hl:Lmop:R:s:u:U", -+#endif -+ long_options, NULL)) != -1) { -+ switch (c) { -+ case 'R': -+ if ( (!VALID (optarg) ) -+ || ( ('/' != optarg[0]) ) ) { ++ int i; ++ char *root; ++ ++ for (i = 0; i < argc; i++) { ++ if (!strcmp (argv[i], "--root") || !strcmp (argv[i], "-R")) { ++ if (i + 1 == argc) { ++ fprintf (stderr, ++ _("%s: option '%s' requires an argument\n"), ++ Prog, argv[i]); ++ exit (E_BAD_ARG); ++ } ++ root = argv[i + 1]; ++ ++ if ( (!VALID (root) ) ++ || ( ('/' != root[0]) ) ) { + fprintf (stderr, + _("%s: invalid chroot path '%s'\n"), -+ Prog, optarg); ++ Prog, root); + exit (E_BAD_ARG); + } -+ newroot = optarg; ++ newroot = root; + + if (access (newroot, F_OK) != 0) { + fprintf(stderr, @@ -1317,7 +1325,6 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c + exit (E_BAD_ARG); + } + break; -+ /* no-op on everything else - they will be hanled by process_flags() */ + } + } +} @@ -1326,7 +1333,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c * process_flags - perform command line argument setting * * process_flags() interprets the command line arguments and sets the -@@ -895,6 +952,7 @@ +@@ -895,6 +950,7 @@ {"move-home", no_argument, NULL, 'm'}, {"non-unique", no_argument, NULL, 'o'}, {"password", required_argument, NULL, 'p'}, @@ -1334,7 +1341,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c #ifdef WITH_SELINUX {"selinux-user", required_argument, NULL, 'Z'}, #endif -@@ -905,9 +963,9 @@ +@@ -905,9 +961,9 @@ }; while ((c = getopt_long (argc, argv, #ifdef WITH_SELINUX @@ -1346,7 +1353,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c #endif long_options, NULL)) != -1) { switch (c) { -@@ -999,6 +1057,9 @@ +@@ -999,6 +1055,9 @@ user_pass = optarg; pflg = true; break; @@ -1356,7 +1363,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c case 's': if (!VALID (optarg)) { fprintf (stderr, -@@ -1715,6 +1776,8 @@ +@@ -1715,6 +1774,8 @@ OPENLOG ("usermod"); diff --git a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb index 5bc4a6183e..25330a4cef 100644 --- a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb +++ b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=08c553a87d4e51bbed50b20e0adcaede \ DEPENDS = "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}" RDEPENDS_${PN} = "${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_PLUGINS}', '', d)}" -PR = "r4" +PR = "r5" SRC_URI = "http://pkg-shadow.alioth.debian.org/releases/${BPN}-${PV}.tar.bz2 \ file://login_defs_pam.sed \ @@ -128,11 +128,13 @@ pkg_postinst_${PN} () { update-alternatives --install ${base_sbindir}/vigr vigr vigr.${PN} 200 if [ "x$D" != "x" ]; then - exit 1 - fi + rootarg="--root=$D" + else + rootarg="" + fi - pwconv - grpconv + pwconv $rootarg + grpconv $rootarg } pkg_prerm_${PN} () { diff --git a/meta/recipes-extended/sudo/files/format-string.patch b/meta/recipes-extended/sudo/files/format-string.patch new file mode 100644 index 0000000000..15056fd4cc --- /dev/null +++ b/meta/recipes-extended/sudo/files/format-string.patch @@ -0,0 +1,33 @@ +This patch, extracted from upstreams sudo-1.8.3p2.patch.gz addresses the +recent Sudo format string vulnerability CVE 2012-0809. + +http://www.sudo.ws/sudo/alerts/sudo_debug.html + +Signed-off-by: Joshua Lock <josh@linux.intel.com> + +Upstream-Status: Backport + +diff -urNa sudo-1.8.3p1/src/sudo.c sudo-1.8.3p2/src/sudo.c +--- sudo-1.8.3p1/src/sudo.c Fri Oct 21 09:01:26 2011 ++++ sudo-1.8.3p2/src/sudo.c Tue Jan 24 15:59:03 2012 +@@ -1208,15 +1208,15 @@ + sudo_debug(int level, const char *fmt, ...) + { + va_list ap; +- char *fmt2; ++ char *buf; + + if (level > debug_level) + return; + +- /* Backet fmt with program name and a newline to make it a single write */ +- easprintf(&fmt2, "%s: %s\n", getprogname(), fmt); ++ /* Bracket fmt with program name and a newline to make it a single write */ + va_start(ap, fmt); +- vfprintf(stderr, fmt2, ap); ++ evasprintf(&buf, fmt, ap); + va_end(ap); +- efree(fmt2); ++ fprintf(stderr, "%s: %s\n", getprogname(), buf); ++ efree(buf); + } diff --git a/meta/recipes-extended/sudo/files/sudo-parallel-build.patch b/meta/recipes-extended/sudo/files/sudo-parallel-build.patch new file mode 100755 index 0000000000..6cfe56dddd --- /dev/null +++ b/meta/recipes-extended/sudo/files/sudo-parallel-build.patch @@ -0,0 +1,15 @@ +Upstream-Status: Accepted + +Index: sudo-1.8.1p2/plugins/sudoers/Makefile.in +=================================================================== +--- sudo-1.8.1p2.orig/plugins/sudoers/Makefile.in ++++ sudo-1.8.1p2/plugins/sudoers/Makefile.in +@@ -164,7 +164,7 @@ sudoers.la: $(SUDOERS_OBJS) libsudoers.l + visudo: libsudoers.la $(VISUDO_OBJS) $(LIBS) + $(LIBTOOL) --mode=link $(CC) -o $@ $(VISUDO_OBJS) $(LDFLAGS) libsudoers.la $(LIBS) $(NET_LIBS) + +-sudoreplay: $(REPLAY_OBJS) $(LIBS) ++sudoreplay: timestr.lo $(REPLAY_OBJS) $(LIBS) + $(LIBTOOL) --mode=link $(CC) -o $@ $(REPLAY_OBJS) $(LDFLAGS) timestr.lo $(REPLAY_LIBS) $(LIBS) + + testsudoers: libsudoers.la $(TEST_OBJS) $(LIBS) diff --git a/meta/recipes-extended/sudo/sudo.inc b/meta/recipes-extended/sudo/sudo.inc index 72a7c167cd..83dd209afa 100644 --- a/meta/recipes-extended/sudo/sudo.inc +++ b/meta/recipes-extended/sudo/sudo.inc @@ -29,11 +29,3 @@ do_install_prepend (){ mkdir -p ${D}/${localstatedir}/lib } -pkg_postinst_${PN} () { - if [ "x$D" != "x" ]; then - exit 1 - fi - - chmod 4111 /usr/bin/sudo - chmod 0440 /etc/sudoers -} diff --git a/meta/recipes-extended/sudo/sudo_1.8.1p2.bb b/meta/recipes-extended/sudo/sudo_1.8.1p2.bb index b56829181a..3694c89a42 100644 --- a/meta/recipes-extended/sudo/sudo_1.8.1p2.bb +++ b/meta/recipes-extended/sudo/sudo_1.8.1p2.bb @@ -1,9 +1,11 @@ require sudo.inc -PR = "r2" +PR = "r4" SRC_URI = "http://ftp.sudo.ws/sudo/dist/sudo-${PV}.tar.gz \ file://libtool.patch \ + file://sudo-parallel-build.patch \ + file://format-string.patch \ ${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '', d)}" PAM_SRC_URI = "file://sudo.pam" @@ -23,4 +25,7 @@ do_install_append () { break fi done + + chmod 4111 $D/usr/bin/sudo + chmod 0440 $D/etc/sudoers } diff --git a/meta/recipes-extended/sysklogd/files/no-vectorization.patch b/meta/recipes-extended/sysklogd/files/no-vectorization.patch new file mode 100644 index 0000000000..c1cc042c9c --- /dev/null +++ b/meta/recipes-extended/sysklogd/files/no-vectorization.patch @@ -0,0 +1,20 @@ +Upstream-Status: Inappropriate + +The compiler should not be generating vectorized instructions on this target. +This is a work around until I can determine why this is occuring on this +particular recipe + +Index: sysklogd-1.5/Makefile +=================================================================== +--- sysklogd-1.5.orig/Makefile ++++ sysklogd-1.5/Makefile +@@ -20,7 +20,8 @@ + CC= gcc + #SKFLAGS= -g -DSYSV -Wall + #LDFLAGS= -g +-SKFLAGS= $(RPM_OPT_FLAGS) -O3 -DSYSV -fomit-frame-pointer -Wall -fno-strength-reduce ++SKFLAGS= $(RPM_OPT_FLAGS) -O3 -DSYSV -fomit-frame-pointer -Wall -fno-strength-reduce \ ++ -fno-tree-vectorize + # -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE + # -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE + # $(shell getconf LFS_SKFLAGS) diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc b/meta/recipes-extended/sysklogd/sysklogd.inc index 891dd3b80f..0b84dace96 100644 --- a/meta/recipes-extended/sysklogd/sysklogd.inc +++ b/meta/recipes-extended/sysklogd/sysklogd.inc @@ -22,6 +22,8 @@ SRC_URI = "http://www.infodrom.org/projects/sysklogd/download/sysklogd-${PV}.tar file://syslog.conf \ " +SRC_URI_append_e500v2 = " file://no-vectorization.patch" + INITSCRIPT_NAME = "syslog" CONFFILES_${PN} = "${sysconfdir}/syslog.conf.${PN}" diff --git a/meta/recipes-extended/sysklogd/sysklogd_1.5.bb b/meta/recipes-extended/sysklogd/sysklogd_1.5.bb index f17c5a2c7c..187c9f49b6 100644 --- a/meta/recipes-extended/sysklogd/sysklogd_1.5.bb +++ b/meta/recipes-extended/sysklogd/sysklogd_1.5.bb @@ -1,5 +1,5 @@ require sysklogd.inc -PR = "r3" +PR = "r4" SRC_URI[md5sum] = "e053094e8103165f98ddafe828f6ae4b" SRC_URI[sha256sum] = "6169b8e91d29288e90404f01462b69e7f2afb1161aa419826fe4736c7f9eb773" diff --git a/meta/recipes-extended/texinfo/texinfo-4.13a/use_host_makedoc.patch b/meta/recipes-extended/texinfo/texinfo-4.13a/use_host_makedoc.patch new file mode 100644 index 0000000000..db41f1a47e --- /dev/null +++ b/meta/recipes-extended/texinfo/texinfo-4.13a/use_host_makedoc.patch @@ -0,0 +1,37 @@ +This patch requires that we also enable building of the +texinfo-native recipe which will install the makedoc tool +for the host machine. + +This patch simply uses the newly installed makedoc tool from +sysroot. + +Upstream-Status: Inappropriate [OE-Specific] + +Signed-off-by: Saul Wold <sgw@linux.intel.com> + +Index: texinfo-4.13/info/Makefile.am +=================================================================== +--- texinfo-4.13.orig/info/Makefile.am 2008-05-22 05:11:33.000000000 -0700 ++++ texinfo-4.13/info/Makefile.am 2011-12-10 12:55:53.604440118 -0800 +@@ -75,7 +75,7 @@ + # more than once. + funs.h: makedoc$(EXEEXT) $(cmd_sources) + rm -f $(generated_sources) +- $(top_builddir)/$(native_tools)/info/makedoc $(cmd_sources) ++ makedoc $(cmd_sources) + + # The following hack is necessary to hint make before the automatic + # dependencies are built. +Index: texinfo-4.13/doc/Makefile.am +=================================================================== +--- texinfo-4.13.orig/doc/Makefile.am 2008-09-18 11:31:56.000000000 -0700 ++++ texinfo-4.13/doc/Makefile.am 2011-12-10 13:04:09.216457601 -0800 +@@ -19,7 +19,7 @@ + + # Use the programs built in our distribution, taking account of possible + # cross-compiling. +-MAKEINFO = $(top_builddir)/$(native_tools)/makeinfo/makeinfo ++MAKEINFO = makeinfo + + # We'd also like to use something like this, but Automake calls + # "install-info" directly. diff --git a/meta/recipes-extended/texinfo/texinfo_4.13a.bb b/meta/recipes-extended/texinfo/texinfo_4.13a.bb index 9f1c04ace1..f205d4e04d 100644 --- a/meta/recipes-extended/texinfo/texinfo_4.13a.bb +++ b/meta/recipes-extended/texinfo/texinfo_4.13a.bb @@ -6,11 +6,14 @@ HOMEPAGE = "http://www.gnu.org/software/texinfo/" SECTION = "console/utils" LICENSE = "GPLv3+" LIC_FILES_CHKSUM = "file://COPYING;md5=adefda309052235aa5d1e99ce7557010" -PR = "r1" +PR = "r2" DEPENDS = "zlib ncurses texinfo-native" DEPENDS_virtclass-native = "zlib-native ncurses-native" +TARGET_PATCH = "file://use_host_makedoc.patch" +TARGET_PATCH_virtclass-native = "" + SRC_URI = "${GNU_MIRROR}/texinfo/texinfo-${PV}.tar.gz \ file://texinfo-4.12-zlib.patch \ file://texinfo-4.13a-data_types.patch \ @@ -19,7 +22,8 @@ SRC_URI = "${GNU_MIRROR}/texinfo/texinfo-${PV}.tar.gz \ file://texinfo-4.13a-help-index-segfault.patch \ file://disable-native-tools.patch \ file://link-zip.patch \ - file://gettext-macros.patch" + file://gettext-macros.patch \ + ${TARGET_PATCH}" SRC_URI[md5sum] = "71ba711519209b5fb583fed2b3d86fcb" SRC_URI[sha256sum] = "1303e91a1c752b69a32666a407e9fbdd6e936def4b09bc7de30f416301530d68" @@ -39,6 +43,9 @@ do_install_append() { mkdir -p ${D}${datadir}/${tex_texinfo} install -p -m644 doc/texinfo.tex doc/txi-??.tex ${D}${datadir}/${tex_texinfo} } +do_install_append_virtclass-native() { + install -m 755 info/makedoc ${D}${bindir} +} PACKAGES += "info info-doc" diff --git a/meta/recipes-extended/which/which_2.20.bb b/meta/recipes-extended/which/which_2.20.bb index 07a5d3104b..a4e860b6c9 100644 --- a/meta/recipes-extended/which/which_2.20.bb +++ b/meta/recipes-extended/which/which_2.20.bb @@ -8,7 +8,9 @@ DEPENDS = "cwautomacros-native" inherit autotools update-alternatives -PR = "r1" +PR = "r2" + +EXTRA_OECONF = "--disable-iberty" SRC_URI = "${GNU_MIRROR}/which/which-${PV}.tar.gz \ file://remove-declaration.patch" diff --git a/meta/recipes-gnome/gnome/gconf-dbus_705.bb b/meta/recipes-gnome/gnome/gconf-dbus_705.bb index fdfc45f5b3..c0c2e28331 100644 --- a/meta/recipes-gnome/gnome/gconf-dbus_705.bb +++ b/meta/recipes-gnome/gnome/gconf-dbus_705.bb @@ -10,7 +10,7 @@ RPROVIDES_${PN}-dev = "gconf-dev" #SRCREV = "705" #PV = "2.16.0+svnr${SRCPV}" -PR = "r0" +PR = "r1" # This SVN repo is no longer available use a tarball mirror site until # we move to proper gconf recipe. @@ -33,6 +33,8 @@ do_configure_prepend() { FILES_${PN} = "${libdir}/GConf-dbus/2/*.so ${libdir}/dbus-1.0 ${sysconfdir} ${datadir}/dbus* ${libdir}/*.so.* ${bindir}/* ${libexecdir}/*" FILES_${PN}-dbg += " ${libdir}/GConf-dbus/2/.debug" +FILES_${PN}-dev += "${datadir}/sgml/gconf/gconf-1.0.dtd \ + ${libdir}/GConf-dbus/2/*.la" BBCLASSEXTEND = "native" diff --git a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb index 570c45a703..8936dbd8b9 100644 --- a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb +++ b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb @@ -6,11 +6,8 @@ LICENSE = "GPLv3" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" SECTION = "x11/gnome" -PR = "r0" -inherit gnome - -# all isn't appropriate since STAGING_DATADIR is target specific -# PACKAGE_ARCH="all" +PR = "r1" +inherit gnome allarch # The omf.make file failed if scrollkeeper doesn't happen to be # installed diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils.inc b/meta/recipes-gnome/gnome/gnome-doc-utils.inc index b1aef3b609..0047a1d15c 100644 --- a/meta/recipes-gnome/gnome/gnome-doc-utils.inc +++ b/meta/recipes-gnome/gnome/gnome-doc-utils.inc @@ -1,6 +1,6 @@ LICENSE = "GPL & LGPL" -DEPENDS = "libxml2 libxslt libxslt-native gnome-doc-utils-native" -DEPENDS_virtclass-native = "libxml2-native libxslt-native intltool-native" +DEPENDS = "libxml2 libxslt libxslt-native gnome-doc-utils-native glib-2.0" +DEPENDS_virtclass-native = "libxml2-native libxslt-native intltool-native glib-2.0-native" inherit gnome gettext python-dir diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils/sysrooted-pkg-config.patch b/meta/recipes-gnome/gnome/gnome-doc-utils/sysrooted-pkg-config.patch new file mode 100644 index 0000000000..e17e8b4ec3 --- /dev/null +++ b/meta/recipes-gnome/gnome/gnome-doc-utils/sysrooted-pkg-config.patch @@ -0,0 +1,37 @@ +In cross environment we have to prepend the sysroot to the path found by +pkgconfig since the path returned from pkgconfig does not have sysroot prefixed +it ends up using the files from host system. Now usually people have gnome installed +so the build succeeds but if you dont have gnome installed on build host then +it wont find the files on host system and packages using gnome-doc-utils wont +compile. + +This should work ok with non sysrooted builds too since in those cases PKG_CONFIG_SYSROOT_DIR +will be empty + +Upstream-Status: Pending + +Signed-off-by: Khem Raj <raj.khem@gmail.com> + +Index: gnome-doc-utils-0.20.6/tools/gnome-doc-utils.make +=================================================================== +--- gnome-doc-utils-0.20.6.orig/tools/gnome-doc-utils.make 2011-09-23 22:22:26.000000000 -0700 ++++ gnome-doc-utils-0.20.6/tools/gnome-doc-utils.make 2011-09-23 22:30:03.479787196 -0700 +@@ -133,12 +133,12 @@ _DOC_ABS_SRCDIR = @abs_srcdir@ + _xml2po ?= `which xml2po` + _xml2po_mode = $(if $(DOC_ID),mallard,docbook) + +-_db2html ?= `$(PKG_CONFIG) --variable db2html gnome-doc-utils` +-_db2omf ?= `$(PKG_CONFIG) --variable db2omf gnome-doc-utils` +-_malrng ?= `$(PKG_CONFIG) --variable malrng gnome-doc-utils` +-_chunks ?= `$(PKG_CONFIG) --variable xmldir gnome-doc-utils`/gnome/xslt/docbook/utils/chunks.xsl +-_credits ?= `$(PKG_CONFIG) --variable xmldir gnome-doc-utils`/gnome/xslt/docbook/utils/credits.xsl +-_ids ?= $(shell $(PKG_CONFIG) --variable xmldir gnome-doc-utils)/gnome/xslt/docbook/utils/ids.xsl ++_db2html ?= ${PKG_CONFIG_SYSROOT_DIR}`$(PKG_CONFIG) --variable db2html gnome-doc-utils` ++_db2omf ?= ${PKG_CONFIG_SYSROOT_DIR}`$(PKG_CONFIG) --variable db2omf gnome-doc-utils` ++_malrng ?= ${PKG_CONFIG_SYSROOT_DIR}`$(PKG_CONFIG) --variable malrng gnome-doc-utils` ++_chunks ?= ${PKG_CONFIG_SYSROOT_DIR}`$(PKG_CONFIG) --variable xmldir gnome-doc-utils`/gnome/xslt/docbook/utils/chunks.xsl ++_credits ?= ${PKG_CONFIG_SYSROOT_DIR}`$(PKG_CONFIG) --variable xmldir gnome-doc-utils`/gnome/xslt/docbook/utils/credits.xsl ++_ids ?= ${PKG_CONFIG_SYSROOT_DIR}$(shell $(PKG_CONFIG) --variable xmldir gnome-doc-utils)/gnome/xslt/docbook/utils/ids.xsl + + if ENABLE_SK + _ENABLE_SK = true diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb b/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb index c65cf640ba..9e3d4c445e 100644 --- a/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb +++ b/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb @@ -1,10 +1,12 @@ require gnome-doc-utils.inc LIC_FILES_CHKSUM = "file://COPYING.GPL;md5=eb723b61539feef013de476e68b5c50a \ file://COPYING.LGPL;md5=a6f89e2100d9b6cdffcea4f398e37343" -PR = "r5" +PR = "r6" SRC_URI += "file://xsltproc_nonet.patch \ - file://use-usr-bin-env-for-python-in-xml2po.patch" + file://use-usr-bin-env-for-python-in-xml2po.patch \ + file://sysrooted-pkg-config.patch \ + " SRC_URI[archive.md5sum] = "8f6e05071599bc073007830ea0a68391" SRC_URI[archive.sha256sum] = "091486e370480bf45349ad09dac799211092a02938b26a0d68206172cb6cebbf" diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb index 55868abf7f..587ac40a1e 100644 --- a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb +++ b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb @@ -22,6 +22,3 @@ SRC_URI[sha256sum] = "ea7e05b77ead159379392b3b275ca0c9cbacd7d936014e447cc7c5e27a EXTRA_OECONF = "--disable-hicolor-check --with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-mapping" inherit autotools - -# We can't do this until the output is shared into all target sysroots -#PACKAGE_ARCH = "all" diff --git a/meta/recipes-gnome/libffi/libffi_3.0.9.bb b/meta/recipes-gnome/libffi/libffi_3.0.9.bb index b6c7c13f32..0ea2284160 100644 --- a/meta/recipes-gnome/libffi/libffi_3.0.9.bb +++ b/meta/recipes-gnome/libffi/libffi_3.0.9.bb @@ -7,10 +7,13 @@ library really only provides the lowest, machine dependent layer of a fully feat A layer must exist above `libffi' that handles type conversions for values passed between the two languages." SRC_URI = "ftp://sourceware.org/pub/libffi/${BPN}-${PV}.tar.gz" +PR = "r1" + SRC_URI[md5sum] = "1f300a7a7f975d4046f51c3022fa5ff1" SRC_URI[sha256sum] = "589d25152318bc780cd8919b14670793f4971d9838dab46ed38c32b3ee92c452" LICENSE = "MIT" LIC_FILES_CHKSUM = "file://LICENSE;md5=fa09cb778aaba64dc9eac37ab7e4e5d8" inherit autotools +FILES_${PN}-dev += "${libdir}/libffi-${PV}" BBCLASSEXTEND = "native" diff --git a/meta/recipes-gnome/libglade/libglade_2.6.4.bb b/meta/recipes-gnome/libglade/libglade_2.6.4.bb index b0e0339554..90a7b33d63 100644 --- a/meta/recipes-gnome/libglade/libglade_2.6.4.bb +++ b/meta/recipes-gnome/libglade/libglade_2.6.4.bb @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605 \ SECTION = "libs" PR = "r1" -DEPENDS = "gtk+ gtk-doc-native" +DEPENDS = "gdk-pixbuf gtk+ gtk-doc-native" inherit autotools pkgconfig gnome diff --git a/meta/recipes-graphics/clutter/clutter-1.6_1.6.14.bb b/meta/recipes-graphics/clutter/clutter-1.6_1.6.14.bb index 555133f482..0aacf0f4a5 100644 --- a/meta/recipes-graphics/clutter/clutter-1.6_1.6.14.bb +++ b/meta/recipes-graphics/clutter/clutter-1.6_1.6.14.bb @@ -1,6 +1,6 @@ require recipes-graphics/clutter/clutter.inc -PR = "r2" +PR = "r3" # Internal json-glib was removed in Clutter 1.5.2 STDDEPENDS += "json-glib" @@ -10,7 +10,9 @@ FILES_${PN}-examples = "${bindir}/test-* ${pkgdatadir}/redhand.png" SRC_URI = "http://source.clutter-project.org/sources/clutter/1.6/clutter-${PV}.tar.bz2 \ file://enable_tests-1.4.patch \ - file://update_gettext_macro_version.patch" + file://update_gettext_macro_version.patch \ + file://fix_build_for_armv4t.patch \ + " LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34" S = "${WORKDIR}/clutter-${PV}" diff --git a/meta/recipes-graphics/clutter/clutter/fix_build_for_armv4t.patch b/meta/recipes-graphics/clutter/clutter/fix_build_for_armv4t.patch new file mode 100644 index 0000000000..28cbfa28f0 --- /dev/null +++ b/meta/recipes-graphics/clutter/clutter/fix_build_for_armv4t.patch @@ -0,0 +1,11 @@ +--- clutter-1.6.14/clutter/cogl/cogl/cogl-fixed.c.ORIG 2011-03-22 15:46:17.000000000 +0100 ++++ clutter-1.6.14/clutter/cogl/cogl/cogl-fixed.c 2011-12-22 09:26:10.650427310 +0100 +@@ -626,7 +626,7 @@ + /* + * Find the highest bit set + */ +-#if __arm__ ++#if __arm__ && !defined(__ARM_ARCH_4T__) + /* This actually requires at least arm v5, but gcc does not seem + * to set the architecture defines correctly, and it is I think + * very unlikely that anyone will want to use clutter on anything diff --git a/meta/recipes-graphics/fontconfig/fontconfig-2.8.0/fix-pkgconfig.patch b/meta/recipes-graphics/fontconfig/fontconfig-2.8.0/fix-pkgconfig.patch index c8a3bf5d17..30415fce76 100644 --- a/meta/recipes-graphics/fontconfig/fontconfig-2.8.0/fix-pkgconfig.patch +++ b/meta/recipes-graphics/fontconfig/fontconfig-2.8.0/fix-pkgconfig.patch @@ -11,5 +11,5 @@ Upstream-Status: Inappropriate [configuration] Version: @VERSION@ Libs: -L${libdir} -lfontconfig -Libs.private: @LIBXML2_LIBS@ @EXPAT_LIBS@ @FREETYPE_LIBS@ @ICONV_LIBS@ -+Libs.private: @LIBXML2_LIBS@ @EXPAT_LIBS@ -L{libdir} -lfreetype @ICONV_LIBS@ ++Libs.private: @LIBXML2_LIBS@ @EXPAT_LIBS@ -L${libdir} -lfreetype @ICONV_LIBS@ Cflags: -I${includedir} diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb b/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb index 5381065256..55c04cc909 100644 --- a/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb +++ b/meta/recipes-graphics/fontconfig/fontconfig_2.8.0.bb @@ -20,7 +20,7 @@ SECTION = "libs" DEPENDS = "expat freetype zlib" -PR = "r3" +PR = "r4" SRC_URI = "http://fontconfig.org/release/fontconfig-${PV}.tar.gz \ file://fix-pkgconfig.patch \ diff --git a/meta/recipes-graphics/libmatchbox/files/16bppfixes.patch b/meta/recipes-graphics/libmatchbox/files/16bppfixes.patch index 284318c948..ac22b9995f 100644 --- a/meta/recipes-graphics/libmatchbox/files/16bppfixes.patch +++ b/meta/recipes-graphics/libmatchbox/files/16bppfixes.patch @@ -1,4 +1,4 @@ -Upstream-Status: Pending +Upstream-Status: Accepted Index: libmb/mbpixbuf.c =================================================================== diff --git a/meta/recipes-graphics/libmatchbox/files/matchbox-start-fix.patch b/meta/recipes-graphics/libmatchbox/files/matchbox-start-fix.patch index 058342c442..88f5d7091b 100644 --- a/meta/recipes-graphics/libmatchbox/files/matchbox-start-fix.patch +++ b/meta/recipes-graphics/libmatchbox/files/matchbox-start-fix.patch @@ -6,7 +6,7 @@ on x86-64. This patch forces a NULL pointer as terminator to fix it. Signed-off-by: Zhai Edwin <edwin.zhai@intel.com> -Upstream-Status: Pending +Upstream-Status: Accepted Index: libmatchbox-1.9/libmb/mbexp.c =================================================================== diff --git a/meta/recipes-graphics/libmatchbox/libmatchbox_git.bb b/meta/recipes-graphics/libmatchbox/libmatchbox_git.bb index d9d4535aa6..ac329e5193 100644 --- a/meta/recipes-graphics/libmatchbox/libmatchbox_git.bb +++ b/meta/recipes-graphics/libmatchbox/libmatchbox_git.bb @@ -1,15 +1,13 @@ require libmatchbox.inc -SRCREV = "c81f8f444b83b187727f046432b186d67a42c732" +SRCREV = "d9dd0ac810de4f0b93cd813ce14aee34c722c2cf" PV = "1.9+git${SRCPV}" PR = "r0" DEFAULT_PREFERENCE = "-1" SRC_URI = "git://git.yoctoproject.org/${BPN};protocol=git \ file://configure_fixes.patch \ - file://check.m4 \ - file://16bppfixes.patch \ - file://matchbox-start-fix.patch" + file://check.m4" S = "${WORKDIR}/git" diff --git a/meta/recipes-graphics/matchbox-wm-2/matchbox-wm-2/fix_makefile.patch b/meta/recipes-graphics/matchbox-wm-2/matchbox-wm-2/fix_makefile.patch index 8c40e85848..1f877d76fe 100644 --- a/meta/recipes-graphics/matchbox-wm-2/matchbox-wm-2/fix_makefile.patch +++ b/meta/recipes-graphics/matchbox-wm-2/matchbox-wm-2/fix_makefile.patch @@ -1,4 +1,6 @@ -Upstream-Status: Pending +Upstream-Status: Accepted +Instead matchbox-window-manager-2, it is in libmatchboxwm2, which has build +failure as partial gtk-doc implementation. Nitin A Kamble <nitin.a.kamble@intel.com> 2011/05/10 Fix following build error: diff --git a/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb b/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb index f58529d3fd..5550dc2b89 100644 --- a/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb +++ b/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = "file://src/wm.h;endline=21;md5=a7e844465edbcf79c282369f93caa SECTION = "x11/wm" DEPENDS = "libmatchbox virtual/libx11 libxext libxrender startup-notification expat gconf" -SRCREV = "e8236c9ab44a8af8137cac2a35fb87f9146a9656" +SRCREV = "f4394eaed475de6e627d373c5b35ee2cf87072e3" PV = "1.2+git${SRCPV}" PR = "r0" diff --git a/meta/recipes-graphics/tslib/tslib/0001-Link-plugins-against-libts.patch b/meta/recipes-graphics/tslib/tslib/0001-Link-plugins-against-libts.patch new file mode 100644 index 0000000000..c6b9f5919b --- /dev/null +++ b/meta/recipes-graphics/tslib/tslib/0001-Link-plugins-against-libts.patch @@ -0,0 +1,57 @@ +From 9623bbedf4ff409e5036edfcfe52b2595932a6d7 Mon Sep 17 00:00:00 2001 +From: Chris Larson <clarson@kergoth.com> +Date: Sat, 1 Nov 2008 20:46:07 +0000 +Subject: [PATCH] Link plugins against libts + +Some plugins use tslib functions. Link those plugins against libts. +The problem is easy to see with LDFLAGS="-Wl,-no-undefined". +Without this change DirectFB in unable to use tslib because symbols +in the tslib plugins can't be resolved. + +Signed-off-by: Ville Syrjala <syrjala@sci.fi> +Signed-off-by: Chris Larson <clarson@kergoth.com> + +The patch was imported from git server git://github.com/kergoth/tslib.git +as of commit id 9623bbedf4ff409e5036edfcfe52b2595932a6d7. + +Upstream-Status: Accepted +Signed-off-by: Dmitry Cherukhin <dima_ch@emcraft.com> +--- + plugins/Makefile.am | 5 +++++ + 1 files changed, 5 insertions(+), 0 deletions(-) + +diff --git a/plugins/Makefile.am b/plugins/Makefile.am +index 3b902c2..4c4ef8b 100644 +--- a/plugins/Makefile.am ++++ b/plugins/Makefile.am +@@ -114,15 +114,19 @@ pluginexec_LTLIBRARIES = \ + + variance_la_SOURCES = variance.c + variance_la_LDFLAGS = -module $(LTVSN) ++variance_la_LIBADD = $(top_builddir)/src/libts.la + + dejitter_la_SOURCES = dejitter.c + dejitter_la_LDFLAGS = -module $(LTVSN) ++dejitter_la_LIBADD = $(top_builddir)/src/libts.la + + linear_la_SOURCES = linear.c + linear_la_LDFLAGS = -module $(LTVSN) ++linear_la_LIBADD = $(top_builddir)/src/libts.la + + pthres_la_SOURCES = pthres.c + pthres_la_LDFLAGS = -module $(LTVSN) ++pthres_la_LIBADD = $(top_builddir)/src/libts.la + + # hw access + corgi_la_SOURCES = corgi-raw.c +@@ -148,6 +152,7 @@ tatung_la_LDFLAGS = -module $(LTVSN) + + input_la_SOURCES = input-raw.c + input_la_LDFLAGS = -module $(LTVSN) ++input_la_LIBADD = $(top_builddir)/src/libts.la + + linear_h2200_la_SOURCES = linear-h2200.c + linear_h2200_la_LDFLAGS = -module $(LTVSN) +-- +1.7.6.4 + diff --git a/meta/recipes-graphics/tslib/tslib_1.0.bb b/meta/recipes-graphics/tslib/tslib_1.0.bb index 3704572baf..dbabce02c0 100644 --- a/meta/recipes-graphics/tslib/tslib_1.0.bb +++ b/meta/recipes-graphics/tslib/tslib_1.0.bb @@ -10,10 +10,11 @@ SECTION = "base" LICENSE = "LGPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=f30a9716ef3762e3467a2f62bf790f0a" -PR = "r18" +PR = "r19" SRC_URI = "http://download.berlios.de/tslib/tslib-${PV}.tar.bz2 \ file://fix_version.patch \ + file://0001-Link-plugins-against-libts.patch \ file://ts.conf \ file://tslib.sh" diff --git a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb index 19bb69c1f3..b0a8242d82 100644 --- a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb +++ b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb @@ -8,11 +8,12 @@ BUGTRACKER = "https://bugzilla.redhat.com/" SECTION = "x11/fonts" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" -PACKAGE_ARCH = "all" RDEPENDS_${PN} = "fontconfig-utils" -PR = "r1" +PR = "r2" PE = "1" +inherit allarch + SRC_URI = "https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-${PV}.tar.gz \ file://30-liberation-aliases.conf" diff --git a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.06.bb b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.06.bb index 4882cc7be3..5193fda3af 100644 --- a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.06.bb +++ b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.06.bb @@ -8,10 +8,9 @@ BUGTRACKER = "https://bugzilla.redhat.com/" SECTION = "x11/fonts" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" -PACKAGE_ARCH = "all" RDEPENDS_${PN} = "fontconfig-utils" PE = "1" -PR = "r1" +PR = "r2" FONTREV = "0.20100721" SRC_URI = "https://fedorahosted.org/releases/l/i/${BPN}/${BPN}-${PV}.${FONTREV}.tar.gz \ @@ -19,6 +18,8 @@ SRC_URI = "https://fedorahosted.org/releases/l/i/${BPN}/${BPN}-${PV}.${FONTREV}. S = ${WORKDIR}/${BPN}-${PV}.${FONTREV} +inherit allarch + do_install () { install -d ${D}${datadir}/fonts/ttf/ for i in *.ttf; do diff --git a/meta/recipes-graphics/ttf-fonts/ttf-bitstream-vera_1.10.bb b/meta/recipes-graphics/ttf-fonts/ttf-bitstream-vera_1.10.bb index 3294b40ae0..682184a95d 100644 --- a/meta/recipes-graphics/ttf-fonts/ttf-bitstream-vera_1.10.bb +++ b/meta/recipes-graphics/ttf-fonts/ttf-bitstream-vera_1.10.bb @@ -7,10 +7,11 @@ but is visibly different than normal and bold, and reasonably pleasing." SECTION = "x11/fonts" LICENSE = "Bitstream_Vera" LIC_FILES_CHKSUM = "file://COPYRIGHT.TXT;md5=27d7484b1e18d0ee4ce538644a3f04be" -PACKAGE_ARCH = "all" -PR = "r4" +PR = "r5" RDEPENDS_${PN} = "fontconfig-utils" +inherit allarch + SRC_URI = "${GNOME_MIRROR}/ttf-bitstream-vera/1.10/ttf-bitstream-vera-${PV}.tar.bz2" do_install () { diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb index ea4222df77..dbc1c42003 100644 --- a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb +++ b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb @@ -2,7 +2,7 @@ DESCRIPTION = "Simple Xserver Init Script (no dm)" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" SECTION = "x11" -PR = "r26" +PR = "r28" RDEPENDS_${PN} = "sudo" SRC_URI = "file://xserver-nodm \ @@ -23,23 +23,15 @@ do_install() { fi } -pkg_postinst_${PN} () { - if [ "x$D" != "x" ] ; then - exit 1 - fi - - if [ -f /etc/X11/Xusername ]; then - # create the rootless X user, and add user to group tty, video, audio - username=`cat /etc/X11/Xusername` - adduser --disabled-password $username - # FIXME: use addgroup if busybox addgroup is ready - sed -i -e "s/^video:.*/&${username}/g" /etc/group - sed -i -e "s/^tty:.*/&${username}/g" /etc/group - sed -i -e "s/^audio:.*/&${username}/g" /etc/group - fi -} - -inherit update-rc.d +inherit update-rc.d useradd INITSCRIPT_NAME = "xserver-nodm" INITSCRIPT_PARAMS = "start 9 5 2 . stop 20 0 1 6 ." + +# Use fixed Xusername of xuser for now, this will need to be +# fixed if the Xusername changes from xuser +USERADD_PACKAGES = "${PN}" +USERADD_PARAM_${PN} = "--system --no-create-home \ + --shell /bin/false --groups video,tty,audio \ + --user-group xuser" + diff --git a/meta/recipes-graphics/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bb b/meta/recipes-graphics/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bb index 002cc1569b..824c295a96 100644 --- a/meta/recipes-graphics/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bb +++ b/meta/recipes-graphics/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bb @@ -6,7 +6,7 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" SECTION = "x11/base" -PR="r3" +PR = "r4" SRC_URI = "http://matchbox-project.org/sources/utils/xcursor-transparent-theme-${PV}.tar.gz \ file://use-relative-symlinks.patch \ @@ -16,6 +16,4 @@ SRC_URI[md5sum] = "7b0c623049d4aab20600d6473f8aab23" SRC_URI[sha256sum] = "b26adf2d503d01299718390ae39dab4691a67220de09423be0364e9a060bf7e4" FILES_${PN} = "${datadir}/icons/xcursor-transparent/cursors/*" -inherit autotools - -PACKAGE_ARCH = "all" +inherit autotools allarch diff --git a/meta/recipes-graphics/xorg-app/xinit_1.3.0.bb b/meta/recipes-graphics/xorg-app/xinit_1.3.0.bb index ee7c64d928..08dfe12007 100644 --- a/meta/recipes-graphics/xorg-app/xinit_1.3.0.bb +++ b/meta/recipes-graphics/xorg-app/xinit_1.3.0.bb @@ -9,9 +9,14 @@ systems. When this first client exits, xinit will kill the X server and \ then terminate." LIC_FILES_CHKSUM = "file://COPYING;md5=0d4b5eef75f1584ccbdc5e4a34314407" -PR = "r0" + +PR = "r2" PE = "1" +EXTRA_OECONF = "ac_cv_path_MCOOKIE=${bindir}/mcookie" + +RDEPENDS_${PN} += "util-linux-mcookie" + FILES_${PN} += "${libdir}X11/xinit" SRC_URI[md5sum] = "bc4e8b7d1919597cc37a0d24aa149dda" diff --git a/meta/recipes-graphics/xorg-font/encodings/nocompiler.patch b/meta/recipes-graphics/xorg-font/encodings/nocompiler.patch new file mode 100644 index 0000000000..1cddd102f5 --- /dev/null +++ b/meta/recipes-graphics/xorg-font/encodings/nocompiler.patch @@ -0,0 +1,31 @@ +XORG_DEFAULT_OPTIONS pulls in the following dependency chains: + +XORG_CWARNFLAGS -> AC_PROG_CC_C99 +XORG_STRICT_OPTION -> AC_PROG_CC_C99, XORG_CWARNFLAGS +XORG_MANPAGE_SECTIONS -> AC_CANONICAL_HOST -> Checks host + +each of which triggers the use of the host compiler. As an "all" +architecture package, it shouldn't need a compiler (and doesn't). + +RP 17/5/2011 + +Index: encodings-1.0.4/configure.ac +=================================================================== +--- encodings-1.0.4.orig/configure.ac 2011-05-17 23:36:19.505095876 +0100 ++++ encodings-1.0.4/configure.ac 2011-05-17 23:54:14.935096128 +0100 +@@ -4,12 +4,12 @@ + AM_INIT_AUTOMAKE([foreign dist-bzip2]) + AM_MAINTAINER_MODE + +-# Require xorg-macros: XORG_DEFAULT_OPTIONS + m4_ifndef([XORG_MACROS_VERSION], + [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])]) + XORG_MACROS_VERSION(1.3) +-XORG_DEFAULT_OPTIONS +- ++XORG_RELEASE_VERSION ++XORG_CHANGELOG ++XORG_INSTALL + AC_PROG_INSTALL + + # Require X.Org's font util macros 1.2 or later diff --git a/meta/recipes-graphics/xorg-font/encodings_1.0.4.bb b/meta/recipes-graphics/xorg-font/encodings_1.0.4.bb index 1345134432..cf7b3e3609 100644 --- a/meta/recipes-graphics/xorg-font/encodings_1.0.4.bb +++ b/meta/recipes-graphics/xorg-font/encodings_1.0.4.bb @@ -7,13 +7,15 @@ require xorg-font-common.inc LICENSE = "PD" LIC_FILES_CHKSUM = "file://COPYING;md5=9da93f2daf2d5572faa2bfaf0dbd9e76" PE = "1" -PR = "${INC_PR}.0" +PR = "${INC_PR}.1" DEPENDS = "mkfontscale-native font-util-native" -EXTRA_OECONF += "--with-encodingsdir=${datadir}/fonts/X11/encodings" +SRC_URI += "file://nocompiler.patch" + +inherit allarch -PACKAGE_ARCH = "all" +EXTRA_OECONF += "--with-encodingsdir=${datadir}/fonts/X11/encodings" SRC_URI[md5sum] = "0f2d6546d514c5cc4ecf78a60657a5c1" SRC_URI[sha256sum] = "ced6312988a45d23812c2ac708b4595f63fd7a49c4dcd9f66bdcd50d1057d539" diff --git a/meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb b/meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb index f1e8648e08..b1a65e7b85 100644 --- a/meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb +++ b/meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb @@ -13,10 +13,11 @@ LIC_FILES_CHKSUM = "file://../misc/fonts.alias;md5=bbe8d3c0e4e74af96e3ac393985c4 SRC_URI = "file://misc" PE = "1" -PR = "r0" +PR = "r1" + +inherit allarch PACKAGES = "${PN}" -PACKAGE_ARCH = "all" FILES_${PN} = "${libdir}/X11/ ${datadir}/fonts/X11/" do_install() { diff --git a/meta/recipes-kernel/kexec/kexec-tools.inc b/meta/recipes-kernel/kexec/kexec-tools.inc index 7541ddcf9e..278ce341d0 100644 --- a/meta/recipes-kernel/kexec/kexec-tools.inc +++ b/meta/recipes-kernel/kexec/kexec-tools.inc @@ -12,4 +12,6 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz inherit autotools -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*)-(linux|freebsd.*)' +COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)' + +INSANE_SKIP_${PN} = "arch" diff --git a/meta/recipes-kernel/linux/linux-tools.inc b/meta/recipes-kernel/linux/linux-tools.inc index 950f1975c1..b667421fb1 100644 --- a/meta/recipes-kernel/linux/linux-tools.inc +++ b/meta/recipes-kernel/linux/linux-tools.inc @@ -1,17 +1,27 @@ # included by kernel recipes if they want to build/provide # perf functionality from their tree. -do_compile_perf_libc-uclibc () { - : -} -do_install_perf_libc-uclibc () { - : + +BUILDPERF = "yes" +BUILDPERF_libc-uclibc = "no" +# perf requires binutils which is GPLv3 licensed, don't prevent the entire kernel +# being built if GPLv3 is in INCOMPATIBLE_LICENSE +python () { + if ((d.getVar("INCOMPATIBLE_LICENSE", True) or "").find("GPLv3") != -1): + # GPLv3, drop perf + d.setVar("BUILDPERF", "no") + d.setVar("PERFDEPENDS", "") } -do_compile_perf() { + +do_compile_perf () { + if [ "${BUILDPERF}" = "yes" ]; then oe_runmake -C ${S}/tools/perf CC="${CC}" LD="${LD}" prefix=${prefix} NO_NEWT=1 NO_DWARF=1 + fi } -fakeroot do_install_perf() { +fakeroot do_install_perf () { + if [ "${BUILDPERF}" = "yes" ]; then oe_runmake -C ${S}/tools/perf CC="${CC}" LD="${LD}" prefix=${prefix} DESTDIR=${D} install NO_NEWT=1 NO_DWARF=1 + fi } @@ -22,9 +32,10 @@ addtask install_perf after do_install before do_package do_compile_perf[umask] = 022 do_install_perf[umask] = 022 -PERFDEPENDS = "virtual/${MLPREFIX}libc:do_populate_sysroot ${MLPREFIX}elfutils:do_populate_sysroot" +PERFDEPENDS = "virtual/${MLPREFIX}libc:do_populate_sysroot ${MLPREFIX}elfutils:do_populate_sysroot ${MLPREFIX}binutils:do_populate_sysroot" PERFDEPENDS_libc-uclibc = "" PERFRDEPENDS = "python perl elfutils" PERFRDEPENDS_libc-uclibc = "" + do_compile_perf[depends] = "${PERFDEPENDS}" RDEPENDS_perf += "${PERFRDEPENDS}" diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb index 9746f1a87a..be3f0f250b 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb @@ -11,17 +11,17 @@ KMACHINE_qemumips = "mti-malta32-be" KBRANCH = "yocto/standard/preempt-rt/base" KBRANCH_qemuppc = "yocto/standard/preempt-rt/qemu-ppc32" -LINUX_VERSION ?= "3.0.4" +LINUX_VERSION ?= "3.0.18" LINUX_KERNEL_TYPE = "preempt-rt" -SRCREV_machine ?= "0936e13cc65d816f1759e2322c5e3fc82a5037f3" -SRCREV_machine_qemuppc ?= "0936e13cc65d816f1759e2322c5e3fc82a5037f3" -SRCREV_meta ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52" +SRCREV_machine ?= "5672d5079f5977087568b2ce350112c6fe0c199c" +SRCREV_machine_qemuppc ?= "a8ff2e2ff60788673ed830d2498046a40cf9d688" +SRCREV_meta ?= "d386e09f316e03061c088d2b13a48605c20fb3a6" -PR = "r1" +PR = "r2" PV = "${LINUX_VERSION}+git${SRCPV}" -SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" +SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0-1.1.x.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" # Omit broken machines from COMPATIBLE_MACHINE # qemuppc hangs at boot diff --git a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb index 34e563cffd..ce7139352c 100644 --- a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb +++ b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb @@ -20,7 +20,7 @@ SRCREV_machine_qemux86-64 = "af2bfbe5f757361b5b027a24d67a93bfdfaaf33c" SRCREV_machine = "4ae8f8605c81c39b959948e23f7123294a5dfb3f" SRCREV_meta = "aeea99683c7283f1f3320bf2ee7085ee252d4e7e" -PR = "r21" +PR = "r22" PV = "${LINUX_VERSION}+git${SRCPV}" SRC_URI = "git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb index c36e8b538c..2b822bb41b 100644 --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb @@ -10,20 +10,21 @@ KMACHINE_qemuarm = "yocto/standard/arm-versatile-926ejs" KBRANCH = ${KMACHINE} -LINUX_VERSION ?= "3.0.4" +LINUX_VERSION ?= "3.0.18" -SRCREV_machine_qemuarm ?= "7908f38ac44359d58c40b166dbb45e48fc58295c" -SRCREV_machine_qemumips ?= "7ea75f58d69293e6b1c2f904f8f5790521a7ccee" -SRCREV_machine_qemuppc ?= "eccd57eaa4c2b580b9adbbc39e19ecbff56779ae" -SRCREV_machine_qemux86 ?= "72671808fdbe69a9fe03fd8f094e7c59da04a28c" -SRCREV_machine_qemux86-64 ?= "2b2d0954a6fd12b4bb7f02f019bc62633c8060a1" -SRCREV_machine ?= "6b2c7d65b844e686eae7d5cccb9b638887afe28e" -SRCREV_meta ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52" +SRCREV_machine_qemuarm ?= "1f3be2c26b6b79cc7c705a033816940a94e89936" +SRCREV_machine_qemumips ?= "be915b8e22e83741425a8a82f4886ef31e181d89" +SRCREV_machine_qemuppc ?= "002b274d2dd8be5b1ade2152d5180f7da773bdad" +SRCREV_machine_qemux86 ?= "d7e81e7f975c57c581ce13446adf023f95d9fd9f" +SRCREV_machine_qemux86-64 ?= "165ee6a9b142853b5f8e9e94613ed9c0db3ec27d" +SRCREV_machine ?= "70ecfb7613ba70f0f8f46cea27b5f9065ad11023" +SRCREV_meta ?= "d386e09f316e03061c088d2b13a48605c20fb3a6" -PR = "r2" + +PR = "r3" PV = "${LINUX_VERSION}+git${SRCPV}" -SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" +SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0-1.1.x.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)" diff --git a/meta/recipes-kernel/lttng/fix-powerpc64.patch b/meta/recipes-kernel/lttng/fix-powerpc64.patch new file mode 100644 index 0000000000..3c3484c678 --- /dev/null +++ b/meta/recipes-kernel/lttng/fix-powerpc64.patch @@ -0,0 +1,17 @@ +Upstream-Status: Submitted + +Add bit to detect if we are running on powerpc64 and treat it the +same as ppc64 + +Index: ust-0.15/configure.ac +=================================================================== +--- ust-0.15.orig/configure.ac ++++ ust-0.15/configure.ac +@@ -111,6 +111,7 @@ changequote([,])dnl + x86_64) LIBFORMAT="elf64-x86-64" ;; + powerpc) LIBFORMAT="elf32-powerpc" ;; + ppc64) LIBFORMAT="elf64-powerpc" ;; ++ powerpc64) LIBFORMAT="elf64-powerpc" ;; + s390) LIBFORMAT="elf32-s390" ;; + s390x) LIBFORMAT="elf64-s390" ;; + armv5) LIBFORMAT="elf32-littlearm"; NO_UNALIGNED_ACCESS=1 ;; diff --git a/meta/recipes-kernel/lttng/lttng-ust_0.15.bb b/meta/recipes-kernel/lttng/lttng-ust_0.15.bb index 915e619c8c..9dd4658643 100644 --- a/meta/recipes-kernel/lttng/lttng-ust_0.15.bb +++ b/meta/recipes-kernel/lttng/lttng-ust_0.15.bb @@ -10,9 +10,10 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=e647752e045a8c45b6f583771bd561ef \ DEPENDS = "liburcu" -PR = "r2" +PR = "r3" SRC_URI = "http://lttng.org/files/ust/releases/ust-${PV}.tar.gz" +SRC_URI_append_powerpc64 = " file://fix-powerpc64.patch" SRC_URI[md5sum] = "86c71486a70695dc0b2171ad16fc82b3" SRC_URI[sha256sum] = "7ff7ecdc051c0649d5fd21b5ceff4895ca95dc34f14cdc04e50de13cfd1903c5" diff --git a/meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch b/meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch new file mode 100644 index 0000000000..041054e6e8 --- /dev/null +++ b/meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch @@ -0,0 +1,35 @@ +Upstream-Status: Backport + +From 4708a509aa9d65ae93e9824e42ddbc6e8d42d90c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel@daenzer.net> +Date: Sat, 27 Aug 2011 20:04:44 +0200 +Subject: [PATCH] Fix PowerPC checks for __NR_perf_counter_open. +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +__ppc__ isn't defined here on Debian powerpc. Grepping through the headers +installed in /usr/include, there are a few references to __ppc__ and +__ppc64__, but I suspect they're for other OSs. + +Signed-off-by: Michel Dänzer <michel@daenzer.net> +--- + collector.c | 2 +- + 1 files changed, 1 insertions(+), 1 deletions(-) + +diff --git a/collector.c b/collector.c +index b28964f..fe16967 100644 +--- a/collector.c ++++ b/collector.c +@@ -175,7 +175,7 @@ sysprof_perf_counter_open (struct perf_counter_attr *attr, + #define __NR_perf_counter_open 337 + #elif defined(__hppa__) + #define __NR_perf_counter_open 318 +-#elif defined(__ppc__) || defined(__ppc64__) ++#elif defined(__powerpc__) || defined(__powerpc64__) + #define __NR_perf_counter_open 319 + #elif defined(__s390__) + #define __NR_perf_counter_open 331 +-- +1.7.6.1 + diff --git a/meta/recipes-kernel/sysprof/files/ppc-macro-fix.patch b/meta/recipes-kernel/sysprof/files/ppc-macro-fix.patch deleted file mode 100644 index a2e015a0c5..0000000000 --- a/meta/recipes-kernel/sysprof/files/ppc-macro-fix.patch +++ /dev/null @@ -1,13 +0,0 @@ -Index: git/collector.c -=================================================================== ---- git.orig/collector.c 2010-12-09 19:42:12.292040001 -0600 -+++ git/collector.c 2010-12-09 19:42:23.352039997 -0600 -@@ -175,7 +175,7 @@ - #define __NR_perf_counter_open 337 - #elif defined(__hppa__) - #define __NR_perf_counter_open 318 --#elif defined(__ppc__) || defined(__ppc64__) -+#elif defined(__powerpc__) || defined(__powerpc64__) - #define __NR_perf_counter_open 319 - #elif defined(__s390__) - #define __NR_perf_counter_open 331 diff --git a/meta/recipes-kernel/sysprof/sysprof_git.bb b/meta/recipes-kernel/sysprof/sysprof_git.bb index 1af5822967..4c98ff68ed 100644 --- a/meta/recipes-kernel/sysprof/sysprof_git.bb +++ b/meta/recipes-kernel/sysprof/sysprof_git.bb @@ -10,11 +10,11 @@ PV = "1.1.6+git${SRCPV}" SRC_URI = "git://git.gnome.org/sysprof;protocol=git \ file://define-NT_GNU_BUILD_ID.patch \ + file://0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch \ " SRC_URI_append_arm = " file://rmb-arm.patch" SRC_URI_append_mips = " file://rmb-mips.patch" -SRC_URI_append_powerpc = " file://ppc-macro-fix.patch" SRC_URI[md5sum] = "80902a7b3d6f7cb83eb6b47e87538747" SRC_URI[sha256sum] = "1c6403278fa4f3b37a1fb9f0784e496dce1703fe84ac03b2650bf469133a0cb3" diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb b/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb index 6f32b57774..7f643b737e 100644 --- a/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb @@ -14,7 +14,7 @@ BBCLASSEXTEND = "native" #FIXME: remove the following ARM_INSTRUCTION_SET = "arm" -PR = "r0" +PR = "r1" SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/alsa-lib-${PV}.tar.bz2 \ file://fix-tstamp-declaration.patch" @@ -29,17 +29,22 @@ EXTRA_OECONF += "${@get_alsa_fpu_setting(bb, d)} " EXTRA_OECONF = "--with-cards=pdaudiocf --with-oss=yes --disable-python" -PACKAGES =+ "alsa-server libasound alsa-conf-base alsa-conf alsa-doc alsa-dev" +EXTRA_OECONF_append_libc-uclibc = " --with-versioned=no " + +PKGSUFFIX = "" +PKGSUFFIX_virtclass-nativesdk = "-nativesdk" + +PACKAGES =+ "alsa-server${PKGSUFFIX} libasound${PKGSUFFIX} alsa-conf-base${PKGSUFFIX} alsa-conf${PKGSUFFIX} alsa-doc${PKGSUFFIX} alsa-dev${PKGSUFFIX}" FILES_${PN}-dbg += "${libdir}/alsa-lib/*/.debu*" -FILES_libasound = "${libdir}/libasound.so.*" -FILES_alsa-server = "${bindir}/*" -FILES_alsa-conf = "${datadir}/alsa/" -FILES_alsa-dev += "${libdir}/pkgconfig/ /usr/include/ ${datadir}/aclocal/*" -FILES_alsa-conf-base = "\ +FILES_libasound${PKGSUFFIX} = "${libdir}/libasound.so.*" +FILES_alsa-server${PKGSUFFIX} = "${bindir}/*" +FILES_alsa-conf${PKGSUFFIX} = "${datadir}/alsa/" +FILES_alsa-dev${PKGSUFFIX} += "${libdir}/pkgconfig/ /usr/include/ ${datadir}/aclocal/*" +FILES_alsa-conf-base${PKGSUFFIX} = "\ ${datadir}/alsa/alsa.conf \ ${datadir}/alsa/cards/aliases.conf \ ${datadir}/alsa/pcm/default.conf \ ${datadir}/alsa/pcm/dmix.conf \ ${datadir}/alsa/pcm/dsnoop.conf" -RDEPENDS_libasound = "alsa-conf-base" +RDEPENDS_libasound${PKGSUFFIX} = "alsa-conf-base${PKGSUFFIX}" diff --git a/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch b/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch index 658e1903d2..5ca8b35142 100644 --- a/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch +++ b/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch @@ -39,15 +39,17 @@ diff --git a/src/libFLAC/Makefile.am b/src/libFLAC/Makefile.am index cbfb0ac..5785372 100644 --- a/src/libFLAC/Makefile.am +++ b/src/libFLAC/Makefile.am -@@ -40,8 +40,13 @@ if FLaC__SYS_DARWIN +@@ -40,8 +40,15 @@ if FLaC__SYS_DARWIN CPUCFLAGS = -faltivec -force_cpusubtype_ALL -DFLAC__NO_ASM else # Linux-gcc for PPC does not have -force_cpusubtype_ALL, it is Darwin-specific +CPUCFLAGS = +if FLaC__CPU_PPC_SPE +else ++if FLaC__USE_ALTIVEC +CPUCFLAGS += -maltivec -mabi=altivec +endif ++endif #@@@ PPC optimizations temporarily disabled -CPUCFLAGS = -maltivec -mabi=altivec -DFLAC__NO_ASM +CPUCFLAGS += -DFLAC__NO_ASM diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb b/meta/recipes-multimedia/flac/flac_1.2.1.bb index 341047abb6..5a9c66f20b 100644 --- a/meta/recipes-multimedia/flac/flac_1.2.1.bb +++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb @@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = "file://COPYING.FDL;md5=ad1419ecc56e060eccf8184a87c4285f \ file://include/FLAC/all.h;beginline=64;endline=69;md5=64474f2b22e9e77b28d8b8b25c983a48" DEPENDS = "libogg" -PR = "r1" +PR = "r2" SRC_URI = "${SOURCEFORGE_MIRROR}/flac/flac-${PV}.tar.gz \ file://disable-xmms-plugin.patch \ @@ -27,7 +27,7 @@ SRC_URI[sha256sum] = "9635a44bceb478bbf2ee8a785cf6986fba525afb5fad1fd4bba73cf71f S = "${WORKDIR}/flac-${PV}" -inherit autotools +inherit autotools gettext EXTRA_OECONF = "--disable-oggtest --disable-id3libtest \ --with-ogg-libraries=${STAGING_LIBDIR} \ @@ -36,6 +36,9 @@ EXTRA_OECONF = "--disable-oggtest --disable-id3libtest \ --without-xmms-exec-prefix \ --without-libiconv-prefix \ --without-id3lib" +EXTRA_OECONF_prepend_e500mc = "--disable-altivec " +EXTRA_OECONF_prepend_e5500 = "--disable-altivec " +EXTRA_OECONF_prepend_e5500-64b = "--disable-altivec " PACKAGES += "libflac libflac++ liboggflac liboggflac++" FILES_${PN} = "${bindir}/*" diff --git a/meta/recipes-multimedia/libomxil/libomxil_0.3.3.bb b/meta/recipes-multimedia/libomxil/libomxil_0.3.3.bb index 665601f11b..da3ddde4ca 100644 --- a/meta/recipes-multimedia/libomxil/libomxil_0.3.3.bb +++ b/meta/recipes-multimedia/libomxil/libomxil_0.3.3.bb @@ -5,6 +5,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=ae6f0f4dbc7ac193b50f323a6ae191cb \ file://src/omxcore.h;beginline=1;endline=27;md5=c2e37f68ba9652ca9b2431f466944174" DEPENDS = "libvorbis libogg alsa-lib libmad" +PR = "r1" + SRC_URI = "${SOURCEFORGE_MIRROR}/omxil/libomxil-B-${PV}.tar.gz" S = "${WORKDIR}/${BPN}-B-${PV}" @@ -13,6 +15,9 @@ inherit autotools EXTRA_OECONF += "--disable-ffmpegcomponents" -FILES_${PN} += "${libdir}/omxilcomponents/*.so*" -FILES_${PN}-dev += "${libdir}/omxilcomponents/*.*a" +FILES_${PN} += "${libdir}/omxilcomponents/*${SOLIBS} \ + ${datadir}/libomxil-B" +FILES_${PN}-staticdev += "${libdir}/omxilcomponents/*.a" +FILES_${PN}-dev += "${libdir}/omxilcomponents/*.la \ + ${libdir}/omxilcomponents/*${SOLIBSDEV}" FILES_${PN}-dbg += "${libdir}/omxilcomponents/.debug/" diff --git a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb index 05b22e8261..c84917a7b3 100644 --- a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb +++ b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb @@ -6,7 +6,7 @@ LICENSE = "GPLv2 & MIT" LIC_FILES_CHKSUM = "file://doc/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ file://doc/LICENSING.txt;md5=607073e04548eac7d1f763e480477bab \ " -PR = "r5" +PR = "r7" SRC_URI = "http://www.hpl.hp.com/research/linux/atomic_ops/download/libatomic_ops-${PV}.tar.gz \ file://fedora/libatomic_ops-1.2-ppclwzfix.patch \ @@ -20,4 +20,10 @@ S = "${WORKDIR}/libatomic_ops-${PV}" ALLOW_EMPTY_${PN} = "1" +ARM_INSTRUCTION_SET = "arm" + inherit autotools pkgconfig + +do_install_append() { + mv ${D}${datadir}/libatomic_ops ${D}${datadir}/libatomic-ops || true +} diff --git a/meta/recipes-multimedia/pulseaudio/libcanberra_0.28.bb b/meta/recipes-multimedia/pulseaudio/libcanberra_0.28.bb index 1922f727b4..2bee07a12f 100644 --- a/meta/recipes-multimedia/pulseaudio/libcanberra_0.28.bb +++ b/meta/recipes-multimedia/pulseaudio/libcanberra_0.28.bb @@ -4,8 +4,8 @@ LICENSE = "LGPLv2.1" LIC_FILES_CHKSUM = "file://LGPL;md5=2d5025d4aa3495befef8f17206a5b0a1 \ file://src/canberra.h;beginline=7;endline=24;md5=c616c687cf8da540a14f917e0d23ab03" -DEPENDS = "gtk+ pulseaudio alsa-lib libtool" -PR = "r0" +DEPENDS = "gtk+ pulseaudio alsa-lib libtool libvorbis" +PR = "r1" inherit gconf autotools diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb index 1edd9138b6..62832d9474 100644 --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb @@ -1,10 +1,10 @@ require pulseaudio.inc -PR = "r4" +PR = "r7" -DEPENDS += "gdbm speex" +DEPENDS += "gdbm speex libxml-parser-perl-native" -inherit gettext +inherit gettext perlnative SRC_URI = "http://freedesktop.org/software/pulseaudio/releases/pulseaudio-${PV}.tar.gz \ file://buildfix.patch \ @@ -23,3 +23,4 @@ do_compile_prepend() { cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl } +ARM_INSTRUCTION_SET = "arm" diff --git a/meta/recipes-qt/meta/meta-toolchain-qte.bb b/meta/recipes-qt/meta/meta-toolchain-qte.bb index 72d58db5e6..735ccd10ab 100644 --- a/meta/recipes-qt/meta/meta-toolchain-qte.bb +++ b/meta/recipes-qt/meta/meta-toolchain-qte.bb @@ -10,6 +10,9 @@ QT_DIR_NAME = "qtopia" QT_TOOLS_PREFIX = "${SDKPATHNATIVE}${bindir_nativesdk}" toolchain_create_sdk_env_script_append() { + echo 'export OE_QMAKE_CFLAGS="$CFLAGS"' >> $script + echo 'export OE_QMAKE_CXXFLAGS="$CXXFLAGS"' >> $script + echo 'export OE_QMAKE_LDFLAGS="$LDFLAGS"' >> $script echo 'export OE_QMAKE_CC=${TARGET_PREFIX}gcc' >> $script echo 'export OE_QMAKE_CXX=${TARGET_PREFIX}g++' >> $script echo 'export OE_QMAKE_LINK=${TARGET_PREFIX}g++' >> $script @@ -24,4 +27,8 @@ toolchain_create_sdk_env_script_append() { echo 'export OE_QMAKE_QDBUSXML2CPP=${QT_TOOLS_PREFIX}/qdbusxml2cpp4' >> $script echo 'export OE_QMAKE_QT_CONFIG=${SDKTARGETSYSROOT}/${datadir}/${QT_DIR_NAME}/mkspecs/qconfig.pri' >> $script echo 'export QMAKESPEC=${SDKTARGETSYSROOT}/${datadir}/${QT_DIR_NAME}/mkspecs/linux-g++' >> $script + + # make a symbolic link to mkspecs for compatibility with Nokia's SDK + # and QTCreator + (cd ${SDK_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s ${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;) } diff --git a/meta/recipes-qt/qt4/qt-4.7.3.inc b/meta/recipes-qt/qt4/qt-4.7.3.inc index a5b8b05bff..16c7b08908 100644 --- a/meta/recipes-qt/qt4/qt-4.7.3.inc +++ b/meta/recipes-qt/qt4/qt-4.7.3.inc @@ -13,6 +13,7 @@ SRC_URI = "http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}. file://0009-support-2bpp.patch \ file://0001-Added-Openembedded-crossarch-option.patch \ file://blacklist-diginotar-certs.diff \ + file://fix-translations.patch \ file://g++.conf \ file://linux.conf \ " @@ -26,7 +27,9 @@ FILES_${QT_BASE_NAME}-tools += "${bindir}/qml" do_configure_prepend() { for pro in $(find ${S} -name "*.pro") ; do - sed -i 's:$$QT_BUILD_TREE/bin/lrelease:${OE_QMAKE_LRELEASE}:g' $pro + sed -i \ + -e 's:$$QT_BUILD_TREE/bin/lrelease:${OE_QMAKE_LRELEASE}:g' \ + -e 's:qtPrepareTool(LRELEASE, lrelease):LRELEASE = ${OE_QMAKE_LRELEASE}:g' $pro done sed -i s:SEDME:${S}: ${WORKDIR}/linux.conf @@ -38,10 +41,6 @@ do_configure_prepend() { ${S}/configure } -do_configure_append() { - sed -e '/QMAKE_TARGET /d' -e '/TARGET /d' -i ${S}/translations/Makefile -} - QT_GLFLAGS ?= "" QT_CONFIG_FLAGS += " -xmlpatterns -no-rpath -qt3support -reduce-relocations -silent ${QT_GLFLAGS}" diff --git a/meta/recipes-qt/qt4/qt-4.7.3/fix-translations.patch b/meta/recipes-qt/qt4/qt-4.7.3/fix-translations.patch new file mode 100644 index 0000000000..906d4e312f --- /dev/null +++ b/meta/recipes-qt/qt4/qt-4.7.3/fix-translations.patch @@ -0,0 +1,32 @@ +fix phony translation linking error + + | .../usr/lib/crt1.o: In function `_start': + | .../../sysdeps/i386/elf/start.S:115: undefined reference to `main' + | collect2: ld returned 1 exit status + +Upstream-Status: Pending + +Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> + +diff --git a/translations/translations.pro b/translations/translations.pro +index cdaf04a..24fa668 100644 +--- a/translations/translations.pro ++++ b/translations/translations.pro +@@ -20,7 +20,7 @@ updateqm.name = LRELEASE ${QMAKE_FILE_IN} + updateqm.CONFIG += no_link + QMAKE_EXTRA_COMPILERS += updateqm + +-isEmpty(vcproj) { ++!isEmpty(vcproj) { + QMAKE_LINK = @: IGNORE THIS LINE + OBJECTS_DIR = + win32:CONFIG -= embed_manifest_exe +@@ -30,7 +30,7 @@ isEmpty(vcproj) { + phony_src.input = PHONY_DEPS + phony_src.output = phony.c + phony_src.variable_out = GENERATED_SOURCES +- phony_src.commands = echo int main() { return 0; } > phony.c ++ phony_src.commands = echo \"int main() { return 0; }\" > phony.c + phony_src.name = CREATE phony.c + phony_src.CONFIG += combine + QMAKE_EXTRA_COMPILERS += phony_src diff --git a/meta/recipes-qt/qt4/qt4-embedded.inc b/meta/recipes-qt/qt4/qt4-embedded.inc index 9914c61d6f..c4e2b488c7 100644 --- a/meta/recipes-qt/qt4/qt4-embedded.inc +++ b/meta/recipes-qt/qt4/qt4-embedded.inc @@ -3,7 +3,7 @@ SECTION = "libs" LICENSE = "LGPLv2.1 | GPLv3" HOMEPAGE = "http://qt.nokia.com" DEPENDS += "directfb tslib" -INC_PR = "r30" +INC_PR = "r33" QT_BASE_NAME ?= "qt4-embedded" QT_BASE_LIB ?= "libqt-embedded" diff --git a/meta/recipes-qt/qt4/qt4-embedded_4.7.3.bb b/meta/recipes-qt/qt4/qt4-embedded_4.7.3.bb index c3f6713199..801b45ab82 100644 --- a/meta/recipes-qt/qt4/qt4-embedded_4.7.3.bb +++ b/meta/recipes-qt/qt4/qt4-embedded_4.7.3.bb @@ -1,9 +1,9 @@ require qt-${PV}.inc require qt4-embedded.inc -PR = "${INC_PR}.1" +PR = "${INC_PR}.2" -QT_CONFIG_FLAGS_append_armv6 = " -no-neon " +QT_CONFIG_FLAGS_append_armv6-vfp = " -no-neon " QT_CONFIG_FLAGS += " \ -exceptions \ diff --git a/meta/recipes-qt/qt4/qt4-native.inc b/meta/recipes-qt/qt4/qt4-native.inc index 59c005926a..ebbee9be25 100644 --- a/meta/recipes-qt/qt4/qt4-native.inc +++ b/meta/recipes-qt/qt4/qt4-native.inc @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE.LGPL;md5=fbc093901857fcd118f065f900982c24 \ file://LICENSE.GPL3;md5=babc5b6b77441da277f5c06b2e547720 \ file://LGPL_EXCEPTION.txt;md5=411080a56ff917a5a1aa08c98acae354" -INC_PR = "r12" +INC_PR = "r13" inherit native diff --git a/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc b/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc index 6c396a5ae4..a71c3ae7b0 100644 --- a/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc +++ b/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc @@ -4,7 +4,7 @@ SECTION = "libs" HOMEPAGE = "http://qt.nokia.com" LICENSE = "LGPLv2.1 | GPLv3" -INC_PR = "r6" +INC_PR = "r7" FILESEXTRAPATHS =. "${FILE_DIRNAME}/qt-${PV}:" @@ -51,10 +51,6 @@ EXTRA_OECONF = "-prefix ${prefix} \ EXTRA_OEMAKE = " " do_configure() { - if [ ! -e bin/qmake ]; then - ln -sf ${STAGING_BINDIR_NATIVE}/qmake2 bin/qmake - fi - if [ ! -e mkspecs/${TARGET_OS}-oe-g++ ]; then ln -sf linux-g++ mkspecs/${TARGET_OS}-oe-g++ fi @@ -62,7 +58,16 @@ do_configure() { cp ../g++.conf mkspecs/common cp ../linux.conf mkspecs/common - (echo o; echo yes) | ./configure ${EXTRA_OECONF} || die "Configuring qt failed. EXTRA_OECONF was ${EXTRA_OECONF}" + # first launch configure to get qmake compiled for the nativesdk + (echo o; echo yes) | CC="${CC}" CXX="${CXX}" ./configure ${EXTRA_OECONF} || true + + # then backup the binary and start again with a qmake which can run on the build host + mv bin/qmake bin/qmake_nativesdk + if [ ! -e bin/qmake ]; then + ln -sf ${STAGING_BINDIR_NATIVE}/qmake2 bin/qmake + fi + + (echo o; echo yes) | CC="${CC}" CXX="${CXX}" ./configure ${EXTRA_OECONF} || die "Configuring qt failed. EXTRA_OECONF was ${EXTRA_OECONF}" } TOBUILD = "\ @@ -91,7 +96,7 @@ do_compile() { do_install() { install -d ${D}${bindir} - install -m 0755 bin/qmake ${D}${bindir}/qmake2 + install -m 0755 bin/qmake_nativesdk ${D}${bindir}/qmake2 for i in moc uic uic3 rcc lrelease lupdate qdbuscpp2xml qdbusxml2cpp; do install -m 0755 bin/${i} ${D}${bindir}/${i}4 done @@ -101,9 +106,4 @@ do_install() { for i in moc uic uic3 rcc lrelease lupdate qdbuscpp2xml qdbusxml2cpp; do \ ln -s ${i}4 ${i}; \ done) - - # make a symbolic link to mkspecs for compatibility with Nokia's SDK - # and QTCreator - (cd ${D}${bindir}/..; ln -s ${TARGET_SYS}/usr/share/qtopia/mkspecs mkspecs;) } - diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc b/meta/recipes-qt/qt4/qt4-x11-free.inc index 0a714be87a..93feb0ed34 100644 --- a/meta/recipes-qt/qt4/qt4-x11-free.inc +++ b/meta/recipes-qt/qt4/qt4-x11-free.inc @@ -5,7 +5,7 @@ HOMEPAGE = "http://qt.nokia.com" SECTION = "x11/libs" DEPENDS += "virtual/libgl virtual/libx11 fontconfig libxft libxext libxrender libxrandr libxcursor" -INC_PR = "r27" +INC_PR = "r30" QT_GLFLAGS ?= "${@base_contains('DISTRO_FEATURES', 'opengl', '-opengl', '-no-opengl', d)} " QT_GLFLAGS_qemux86 = "-opengl" diff --git a/meta/recipes-qt/qt4/qt4-x11-free_4.7.3.bb b/meta/recipes-qt/qt4/qt4-x11-free_4.7.3.bb index 75c6314e7f..413afb4a2d 100644 --- a/meta/recipes-qt/qt4/qt4-x11-free_4.7.3.bb +++ b/meta/recipes-qt/qt4/qt4-x11-free_4.7.3.bb @@ -1,9 +1,9 @@ require qt4-x11-free.inc require qt-${PV}.inc -PR = "${INC_PR}.1" +PR = "${INC_PR}.2" -QT_CONFIG_FLAGS_append_armv6 = " -no-neon " +QT_CONFIG_FLAGS_append_armv6-vfp = " -no-neon " QT_CONFIG_FLAGS += " \ -no-embedded \ diff --git a/meta/recipes-qt/qt4/qt4.inc b/meta/recipes-qt/qt4/qt4.inc index 5545be700a..9ff33eca74 100644 --- a/meta/recipes-qt/qt4/qt4.inc +++ b/meta/recipes-qt/qt4/qt4.inc @@ -50,7 +50,7 @@ python __anonymous () { ${libdir}/lib%(name)s${QT_LIBINFIX}.so ${includedir}/${QT_DIR_NAME}/%(incname)s ${libdir}/pkgconfig/%(name)s${QT_LIBINFIX}.pc""" % locals(), d) - bb.data.setVar("FILES_%s-dbg" % pkg, "${libdir}/.debug/lib%(name)s${QT_LIBINFIX}.so.*" % locals(), d) + bb.data.setVar("FILES_%s-dbg" % pkg, "${libdir}/.debug/lib%(name)s${QT_LIBINFIX}.so*" % locals(), d) bb.data.setVar("RRECOMMENDS_%s-dbg" % pkg, "${PN}-dbg", d) lib_packages.append(pkg) dev_packages.append("%s-dev" % pkg) @@ -67,7 +67,7 @@ python __anonymous () { ${libdir}/lib%(name)s.so ${includedir}/${QT_DIR_NAME}/%(incname)s ${libdir}/pkgconfig/%(name)s.pc""" % locals(), d) - bb.data.setVar("FILES_%s-dbg" % pkg, "${libdir}/.debug/lib%(name)s.so.*" % locals(), d) + bb.data.setVar("FILES_%s-dbg" % pkg, "${libdir}/.debug/lib%(name)s.so*" % locals(), d) bb.data.setVar("RRECOMMENDS_%s-dbg" % pkg, "${PN}-dbg", d) lib_packages.append(pkg) dev_packages.append("%s-dev" % pkg) @@ -102,7 +102,7 @@ OTHER_PACKAGES = "\ ${QT_BASE_NAME}-qml-plugins" PACKAGES += "${LIB_PACKAGES} ${DEV_PACKAGES} ${DBG_PACKAGES} ${OTHER_PACKAGES}" -PACKAGES_DYNAMIC = "${QT_BASE_NAME}-plugin-* ${QT_BASE_NAME}-translation-* ${QT_BASE_NAME}-fonts-*" +PACKAGES_DYNAMIC = "${QT_BASE_NAME}-plugin-* ${QT_BASE_NAME}-translation-* ${QT_BASE_NAME}-phrasebook-* ${QT_BASE_NAME}-fonts-*" ALLOW_EMPTY_${PN} = "1" ALLOW_EMPTY_${QT_BASE_NAME}-fonts = "1" @@ -152,6 +152,7 @@ FILES_${QT_BASE_NAME}-fonts-ttf-dejavu = "${libdir}/fonts/DejaVu*.ttf" FILES_${QT_BASE_NAME}-fonts-pfa = "${libdir}/fonts/*.pfa" FILES_${QT_BASE_NAME}-fonts-pfb = "${libdir}/fonts/*.pfb" FILES_${QT_BASE_NAME}-fonts-qpf = "${libdir}/fonts/*.qpf" +FILES_${QT_BASE_NAME}-fonts = "${libdir}/fonts/README ${libdir}/fonts/fontdir" FILES_${QT_BASE_NAME}-linguist = "${bindir}/*linguist* ${bindir}/lrelease ${bindir}/lupdate ${bindir}/lconvert ${bindir}/qm2ts" FILES_${QT_BASE_NAME}-linguist-dbg = "${bindir}/.debug/*linguist* ${bindir}/.debug/lrelease ${bindir}/.debug/lupdate ${bindir}/.debug/lconvert ${bindir}/.debug/qm2ts" FILES_${QT_BASE_NAME}-pixeltool = "${bindir}/pixeltool" @@ -166,7 +167,7 @@ FILES_${QT_BASE_NAME}-mkspecs = "${datadir}/${QT_DIR_NAME}/mkspecs/ FILES_${QT_BASE_NAME}-xmlpatterns = "${bindir}/xmlpatterns*" FILES_${QT_BASE_NAME}-xmlpatterns-dbg = "${bindir}/.debug/xmlpatterns*" FILES_${QT_BASE_NAME}-qml-plugins = "${libdir}/${QT_DIR_NAME}/imports/* ${libdir}/${QT_DIR_NAME}/plugins/qmltooling/*" -FILES_${QT_BASE_NAME}-qml-plugins-dbg = "${libdir}/${QT_DIR_NAME}/imports/*/*/*/.debug/* ${libdir}/${QT_DIR_NAME}/imports/*/.debug" +FILES_${QT_BASE_NAME}-qml-plugins-dbg = "${libdir}/${QT_DIR_NAME}/imports/*/*/*/.debug/* ${libdir}/${QT_DIR_NAME}/imports/*/.debug ${libdir}/${QT_DIR_NAME}/plugins/qmltooling/.debug" do_configure() { unset QMAKESPEC @@ -228,8 +229,10 @@ python populate_packages_prepend() { phrasebook_dir = bb.data.expand('${datadir}/${QT_DIR_NAME}/phrasebooks/', d) phrasebook_name = bb.data.expand('${QT_BASE_NAME}-phrasebook-%s', d) import os; - if os.path.exists(phrasebook_dir): + if os.path.exists("%s%s" % (bb.data.expand('${D}',d), phrasebook_dir)): do_split_packages(d, phrasebook_dir, '^(.*)\.qph$', phrasebook_name, '${PN} phrasebook for %s', extra_depends='' ) + else: + bb.note("The path does not exist:", bb.data.expand('${D}', d), phrasebook_dir) # Package all the plugins and their -dbg version and create a meta package def qtopia_split(path, name, glob): @@ -286,14 +289,13 @@ do_install() { rm -f ${D}/${bindir}/lrelease # fix pkgconfig, libtool and prl files - sed -i -e s#-L${S}/lib##g \ - -e s#-L${STAGING_LIBDIR}##g \ + sed -i -e s#-L${S}/lib/\?##g \ + -e s#-L${STAGING_LIBDIR}/\?##g \ -e 's#STAGING_LIBDIR}#libdir}'#g \ - -e s#-L${libdir}##g \ + -e s#-L${libdir}/\?##g \ -e s#'$(OE_QMAKE_LIBS_X11)'#"${OE_QMAKE_LIBS_X11}"#g \ - -e s#" -Wl,-rpath-link,${S}/lib"##g \ - -e s#" -Wl,-rpath-link,${libdir}"##g \ - -e 's#I/usr/include#Iincludedir}#g' \ + -e s#" -Wl,-rpath-link,${S}/lib/\?"##g \ + -e s#" -Wl,-rpath-link,${libdir}/\?"##g \ -e 's#Iin#I${in#g' \ ${D}${libdir}/*.la ${D}${libdir}/*.prl ${D}${libdir}/pkgconfig/*.pc @@ -310,8 +312,7 @@ do_install() { # QT abuses $includedir to point to its headers, which breaks pkgconfig sysroot, so manually fix it up here: for pc in ${D}${libdir}/pkgconfig/*.pc ; do - sed -i -e "s:prefix}include/${QT_BASE_NAME}/$(basename $pc .pc):prefix}/include:" \ - -e "s,Cflags: ,Cflags: -IP{includedir}/${QT_BASE_NAME}/$(basename $pc .pc) ," \ + sed -i -e "s:prefix}include/${QT_DIR_NAME}/$(basename $pc .pc):prefix}/include:" \ -e 's:IP{:I${:g' $pc done diff --git a/meta/recipes-sato/eds/eds-tools_bzr.bb b/meta/recipes-sato/eds/eds-tools_git.bb index afa80004e4..fedfaf5bc5 100644 --- a/meta/recipes-sato/eds/eds-tools_bzr.bb +++ b/meta/recipes-sato/eds/eds-tools_git.bb @@ -4,10 +4,10 @@ DEPENDS = "dbus-glib eds-dbus" RDEPENDS_${PN} = "libedata-book" DESCRIPTION = "Test applications for EDS" -SRCREV = "2008-02-04" -PR = "r1" +SRCREV = "882df681014cf42f75882995e507c75254b6b62f" +PR = "r0" -SRC_URI = "bzr://burtonini.com/bzr/eds-tools;proto=http" +SRC_URI = "git://github.com/rossburton/eds-tools.git;protocol=git" LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" diff --git a/meta/recipes-sato/matchbox-desktop/files/dso_linking_change_build_fix.patch b/meta/recipes-sato/matchbox-desktop/files/dso_linking_change_build_fix.patch index 0edb55e081..388f51f07f 100644 --- a/meta/recipes-sato/matchbox-desktop/files/dso_linking_change_build_fix.patch +++ b/meta/recipes-sato/matchbox-desktop/files/dso_linking_change_build_fix.patch @@ -11,7 +11,7 @@ This patch avoids this linking error: Nitin A Kamble <nitin.a.kamble@intel.com> Date: 2011/01/11 -Upstream-Status: Pending +Upstream-Status: Accepted Index: matchbox-desktop-2/configure.ac =================================================================== diff --git a/meta/recipes-sato/matchbox-desktop/files/window-resize-fix.patch b/meta/recipes-sato/matchbox-desktop/files/window-resize-fix.patch deleted file mode 100644 index 8970ac8445..0000000000 --- a/meta/recipes-sato/matchbox-desktop/files/window-resize-fix.patch +++ /dev/null @@ -1,50 +0,0 @@ -commit 2ef9a98cbda46b5a52e20ce292eebd6ba1f3c3a8 -Author: Yu Ke <ke.yu@intel.com> -Date: Sun Mar 6 17:58:45 2011 +0800 - - desktop: Add configure event handler for desktop resize - - desktop need to resize its work area when window manager decorate its - window. Originally it is done by the hook in root window PropertyNotify - event handler, i.e. net_workarea_changed () routine. However, for unknown - reason, the PropertyNotify event does not deliver to the root window, - thus this routine does not work. - - this patch fix this issue from another side. Since window manager will also - send configure event to desktop window after decoration, it also works to do - it in configure event handler. - - Signed-off-by: Yu Ke <ke.yu@intel.com> - -Upstream-Status: Pending - -diff --git a/src/desktop.c b/src/desktop.c -index d4fc2fb..5aa2cfc 100644 ---- a/src/desktop.c -+++ b/src/desktop.c -@@ -130,6 +130,15 @@ workarea_changed (int x, int y, int w, int h) - gtk_fixed_move (GTK_FIXED (fixed), box, x, y); - } - -+static gboolean -+desktop_configure_callback(GtkWindow *window, -+ GdkEvent *event, gpointer data) -+{ -+ gtk_widget_set_size_request (box, event->configure.width, event->configure.height); -+ gtk_widget_queue_resize (box); -+ return FALSE; -+} -+ - GtkWidget * - create_desktop (void) - { -@@ -176,6 +185,9 @@ create_desktop (void) - /* Set a sane default in case there is no work area defined yet */ - workarea_changed (0, 0, screen_w, screen_h); - -+ g_signal_connect(G_OBJECT(window), "configure-event", -+ G_CALLBACK(desktop_configure_callback), NULL); -+ - #ifdef STANDALONE - /* TODO: fake workarea_changed calls on window resize */ - #else diff --git a/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb b/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb index a3dcec32f0..e2e3047f35 100644 --- a/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb +++ b/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb @@ -10,13 +10,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ DEPENDS = "gtk+ startup-notification dbus" SECTION = "x11/wm" -SRCREV = "af7ed6775487380be73160aa0298bf6019765fad" +SRCREV = "71e3e6e04271e9d5a14f1c231ef100c7f320134d" PV = "2.0+git${SRCPV}" -PR = "r1" +PR = "r0" -SRC_URI = "git://git.yoctoproject.org/${BPN}-2;protocol=git \ - file://dso_linking_change_build_fix.patch \ - file://window-resize-fix.patch" +SRC_URI = "git://git.yoctoproject.org/${BPN}-2;protocol=git" EXTRA_OECONF = "--enable-startup-notification --with-dbus" diff --git a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb index 98b3447a71..c1da0cf62a 100644 --- a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb +++ b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb @@ -11,17 +11,16 @@ DEPENDS = "gtk+ startup-notification dbus dbus-glib" DEPENDS += " ${@base_contains("MACHINE_FEATURES", "acpi", "libacpi", "",d)}" DEPENDS += " ${@base_contains("MACHINE_FEATURES", "apm", "apmd", "",d)}" -SRCREV = "982d9ea173dc87a84db2303d1a6a12607fc4d539" +SRCREV = "cdf7a22716b87468f10573f622d5c7a58a684e35" PV = "0.0+git${SRCPV}" -PR = "r1" +PR = "r0" RPROVIDES_${PN} = "matchbox-panel" RREPLACES_${PN} = "matchbox-panel" RCONFLICTS_${PN} = "matchbox-panel" SRC_URI = "git://git.yoctoproject.org/${BPN};protocol=git \ - file://gcc-4.6.0-compile.patch \ - file://startup_fix.diff" + file://gcc-4.6.0-compile.patch" EXTRA_OECONF = "--enable-startup-notification --enable-dbus" EXTRA_OECONF += " ${@base_contains("MACHINE_FEATURES", "acpi", "--with-battery=acpi", "",d)}" diff --git a/meta/recipes-sato/matchbox-panel-2/startup_fix.diff b/meta/recipes-sato/matchbox-panel-2/startup_fix.diff deleted file mode 100644 index d9a0876296..0000000000 --- a/meta/recipes-sato/matchbox-panel-2/startup_fix.diff +++ /dev/null @@ -1,19 +0,0 @@ -Fixed the compile error caused by typo, upstream also need this. - -Signed-off-by: Zhai Edwin <edwin.zhai@intel.com> - -Upstream-Status: Pending - -Index: matchbox-panel-2/applets/startup/startup.c -=================================================================== ---- matchbox-panel-2/applets/startup/startup.c (revision 2109) -+++ matchbox-panel-2/applets/startup/startup.c (working copy) -@@ -229,7 +229,7 @@ - applet = g_slice_new0 (StartupApplet); - - applet->launch_list = NULL; -- applet->hourglass_show = FALSE; -+ applet->hourglass_shown = FALSE; - - /* Create image */ - applet->image = MB_PANEL_SCALING_IMAGE diff --git a/meta/recipes-sato/matchbox-stroke/files/dso_linking_change_build_fix.patch b/meta/recipes-sato/matchbox-stroke/files/dso_linking_change_build_fix.patch deleted file mode 100644 index cbfa7dee69..0000000000 --- a/meta/recipes-sato/matchbox-stroke/files/dso_linking_change_build_fix.patch +++ /dev/null @@ -1,37 +0,0 @@ -after gcc linking has changed, all the libraries must be explicitely specified -This patch avoids these linking errors: - -| make[1]: Entering directory `/disk0/pokybuild/build1/tmp/work/i586-poky-linux/matchbox-stroke-0.0+svnr1820-r0/matchbox-stroke'^M -| Making all in src^M -| make[2]: Entering directory `/disk0/pokybuild/build1/tmp/work/i586-poky-linux/matchbox-stroke-0.0+svnr1820-r0/matchbox-stroke/src'^M -| ccache i586-poky-linux-gcc -march=i586 --sysroot=/disk0/pokybuild/build1/tmp/sysroots/i586-poky-linux -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o matchbox-stroke matchbox-stroke.o matchbox-stroke-ui.o matchbox-stroke-recog.o matchbox-stroke-mode.o matchbox-stroke-action.o config-parser.o util-hash.o util.o -lXft -lX11 -lXtst -lfakekey -lexpat -lm^M -| /disk0/pokybuild/build1/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.5.1/ld: u: invalid DSO for symbol `XRenderFindVisualFormat' definition^M -| /disk0/pokybuild/build1/tmp/sysroots/i586-poky-linux/usr/lib/libXrender.so.1: could not read symbols: Bad value^M -| collect2: ld returned 1 exit status^M -| make[2]: *** [matchbox-stroke] Error 1 - -Nitin A Kamble <nitin.a.kamble@intel.com> -Date: 2011/01/11 - -Upstream-Status: Pending - -Index: matchbox-stroke/configure.ac -=================================================================== ---- matchbox-stroke.orig/configure.ac -+++ matchbox-stroke/configure.ac -@@ -38,7 +38,7 @@ AC_ARG_WITH(expat-lib, - expat_lib=$withval, expat_lib=yes) - - --PKG_CHECK_MODULES(MBSTROKE, xft libfakekey,, -+PKG_CHECK_MODULES(MBSTROKE, xft libfakekey xrender,, - AC_MSG_ERROR([*** Required Librarys not found ***])) - - dnl ------ Expat ------------------------------------------------------------ -@@ -160,4 +160,4 @@ echo " - compiler: ${CC} - - Building with Debug: ${enable_debug} --" -\ No newline at end of file -+" diff --git a/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb b/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb index 10388f4c71..44b316ddef 100644 --- a/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb +++ b/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb @@ -13,8 +13,7 @@ PR = "r0" SRC_URI = "git://git.yoctoproject.org/${BPN};protocol=git \ file://single-instance.patch \ - file://configure_fix.patch;maxrev=1819 \ - file://dso_linking_change_build_fix.patch " + file://configure_fix.patch;maxrev=1819" S = "${WORKDIR}/git" diff --git a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato-2/png_rename.patch b/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato-2/png_rename.patch deleted file mode 100644 index d8f264fc2a..0000000000 --- a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato-2/png_rename.patch +++ /dev/null @@ -1,16 +0,0 @@ -Background Image name was changed from background.png to template.png - -Signed-off-by: Saul Wold <sgw@linux.intel.com> - -Upstream-Status: Pending - -Index: matchbox-sato/Sato/matchbox2/Makefile.am -=================================================================== ---- matchbox-sato.orig/Sato/matchbox2/Makefile.am 2010-12-29 13:08:43.000000000 -0800 -+++ matchbox-sato/Sato/matchbox2/Makefile.am 2010-12-29 22:14:45.690428881 -0800 -@@ -1,4 +1,4 @@ --pngs = background.png -+pngs = template.png - - themesdir = $(datadir)/themes/Sato/matchbox2 - themes_DATA = theme.xml $(pngs) diff --git a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato-2_git.bb b/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato-2_git.bb index d6bfb2f8fb..3edc3a361b 100644 --- a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato-2_git.bb +++ b/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato-2_git.bb @@ -1,11 +1,10 @@ require matchbox-theme-sato.inc DEPENDS = "matchbox-wm-2" -SRCREV = "f72cf4ed7d71ad9e47b0f2d3dbc593bc2f3e76f8" +SRCREV = "e3ccc08d4a680d70fd4891fca966aa6ce503065c" PV = "0.2+git${SRCPV}" -SRC_URI = "git://git.yoctoproject.org/matchbox-sato;protocol=git \ - file://png_rename.patch" +SRC_URI = "git://git.yoctoproject.org/matchbox-sato;protocol=git" S = "${WORKDIR}/git" diff --git a/meta/recipes-sato/pimlico/contacts.inc b/meta/recipes-sato/pimlico/contacts.inc index ce990d7ddd..52c65ec128 100644 --- a/meta/recipes-sato/pimlico/contacts.inc +++ b/meta/recipes-sato/pimlico/contacts.inc @@ -23,7 +23,8 @@ do_install_append () { } FILES_${PN} += "${datadir}/pixmaps/stock_contact.png \ - ${datadir}/pixmaps/stock_person.png" + ${datadir}/pixmaps/stock_person.png \ + ${datadir}/icons/hicolor" SRC_URI = "file://stock_contact.png \ file://stock_person.png" diff --git a/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc b/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc index 0eff9dd7ae..75e029c0e8 100644 --- a/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc +++ b/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc @@ -8,12 +8,10 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=56a830bbe6e4697fe6cbbae01bb7c2b2" SECTION = "x11" DEPENDS = "" -inherit autotools pkgconfig +inherit autotools pkgconfig allarch FILES_${PN} += "${datadir}" -PACKAGE_ARCH = "all" - EXTRA_OECONF += "--with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-mapping" #explictly setting "Sato" as default icon theme to avoid icon missing due to diff --git a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb index e69481de3a..54e46277ff 100644 --- a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb +++ b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb @@ -2,6 +2,8 @@ require sato-icon-theme.inc DEPENDS += "icon-naming-utils-native" +PR = "r1" + SRC_URI = "http://pokylinux.org/releases/sato/${BPN}-${PV}.tar.gz \ file://iconpath-option.patch" diff --git a/meta/recipes-sato/webkit/webkit-gtk_svn.bb b/meta/recipes-sato/webkit/webkit-gtk_svn.bb index 5eb9b2efc7..1cdb80005b 100644 --- a/meta/recipes-sato/webkit/webkit-gtk_svn.bb +++ b/meta/recipes-sato/webkit/webkit-gtk_svn.bb @@ -14,7 +14,7 @@ SRCREV_FORMAT = "source" SRCREV = "90727" PV = "1.5.1+svnr${SRCPV}" -PR = "r0" +PR = "r1" SRC_URI = "\ svn://svn.webkit.org/repository/webkit/trunk/;module=Source;proto=http;name=source \ @@ -45,6 +45,22 @@ EXTRA_OECONF = "\ EXTRA_AUTORECONF = " -I Source/autotools " +#| ./Source/JavaScriptCore/heap/HandleTypes.h: In static member function 'static T* JSC::HandleTypes<T>::getFromSlot(JSC::HandleSlot) [with T = JSC::Structure, JSC::HandleTypes<T>::ExternalType = JSC::Structure*, JSC::HandleSlot = JSC::JSValue*]': +#| ./Source/JavaScriptCore/heap/Handle.h:141:79: instantiated from 'JSC::Handle<T>::ExternalType JSC::Handle<T>::get() const [with T = JSC::Structure, JSC::Handle<T>::ExternalType = JSC::Structure*]' +#| ./Source/JavaScriptCore/runtime/ScopeChain.h:39:75: instantiated from here +#| ./Source/JavaScriptCore/heap/HandleTypes.h:38:130: warning: cast from 'JSC::JSCell*' to 'JSC::HandleTypes<JSC::Structure>::ExternalType {aka JSC::Structure*}' increases required alignment of target type [-Wcast-align] +#| {standard input}: Assembler messages: +#| {standard input}:28873: Error: invalid immediate: 983040 is out of range +#| {standard input}:28873: Error: value of 983040 too large for field of 2 bytes at 15110 +#| /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv4t-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.2/as: BFD (GNU Binutils) 2.21.1 assertion fail /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/binutils-cross-2.21.1a-r0/binutils-2.21.1/bfd/elf.c:2819 +#| arm-oe-linux-gnueabi-g++: internal compiler error: Segmentation fault (program as) +#| Please submit a full bug report, +#| with preprocessed source if appropriate. +#| See <http://gcc.gnu.org/bugs.html> for instructions. +#| make[1]: *** [Source/JavaScriptCore/jit/libjavascriptcoregtk_1_0_la-JIT.lo] Error 1 +#| make[1]: Leaving directory `/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0' +ARM_INSTRUCTION_SET = "arm" + do_configure_append() { # somethings wrong with icu, fix it up manually for makefile in $(find ${S} -name "GNUmakefile") ; do diff --git a/meta/recipes-support/apr/apr_1.4.5.bb b/meta/recipes-support/apr/apr_1.4.5.bb index b65e0427da..173402a002 100644 --- a/meta/recipes-support/apr/apr_1.4.5.bb +++ b/meta/recipes-support/apr/apr_1.4.5.bb @@ -47,7 +47,7 @@ apr_sysroot_preprocess () { cp ${S}/build/apr_rules.mk $d/ sed -i s,apr_builddir=.*,apr_builddir=,g $d/apr_rules.mk sed -i s,apr_builders=.*,apr_builders=,g $d/apr_rules.mk - sed -i s,LIBTOOL=.*,LIBTOOL=\$\(SHELL\)\ ${TARGET_PREFIX}libtool,g $d/apr_rules.mk + sed -i s,LIBTOOL=.*,LIBTOOL=\$\(SHELL\)\ ${HOST_SYS}-libtool,g $d/apr_rules.mk sed -i s,\$\(apr_builders\),${STAGING_DATADIR}/apr/,g $d/apr_rules.mk cp ${S}/build/mkdir.sh $d/ cp ${S}/build/make_exports.awk $d/ diff --git a/meta/recipes-support/aspell/aspell_0.60.6.1.bb b/meta/recipes-support/aspell/aspell_0.60.6.1.bb index d773ee3d08..64611cbf12 100644 --- a/meta/recipes-support/aspell/aspell_0.60.6.1.bb +++ b/meta/recipes-support/aspell/aspell_0.60.6.1.bb @@ -6,7 +6,7 @@ DESCRIPTION = "GNU Aspell spell-checker" SECTION = "console/utils" LICENSE="LGPLv2 | LGPLv2.1" LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34" -PR = "r0" +PR = "r1" PACKAGES += "libaspell libpspell libpspell-dev aspell-utils" FILES_${PN}-dbg += "${libdir}/aspell-0.60/.debu*" @@ -16,4 +16,5 @@ FILES_${PN} = "${bindir}/aspell" FILES_libpspell = "${libdir}/libpspell.so.*" FILES_libpspell-dev = "${libdir}/libpspell* ${bindir}/pspell-config ${includedir}/pspell" +ARM_INSTRUCTION_SET = "arm" inherit autotools gettext diff --git a/meta/recipes-support/attr/ea-acl.inc b/meta/recipes-support/attr/ea-acl.inc index 22d7848fbf..6a45858b20 100644 --- a/meta/recipes-support/attr/ea-acl.inc +++ b/meta/recipes-support/attr/ea-acl.inc @@ -37,6 +37,9 @@ LDFLAGS_append_libc-uclibc = "${@['', ' -lintl '][(bb.data.getVar('PN', d, True) EXTRA_OECONF_append_libc-uclibc = "${@['', ' --disable-gettext '][(bb.data.getVar('PN', d, True) == bb.data.getVar('BPN', d , True)) and (bb.data.getVar('USE_NLS', d, True) == 'no')]}" fix_symlink () { + if test "${libdir}" = "${base_libdir}" ; then + return + fi # Remove bad symlinks & create the correct symlinks if test -L ${libdir}/lib${BPN}.so ; then rm -rf ${libdir}/lib${BPN}.so diff --git a/meta/recipes-support/gmp/gmp_5.0.2.bb b/meta/recipes-support/gmp/gmp_5.0.2.bb index 03fef453e9..16bdcbc2b7 100644 --- a/meta/recipes-support/gmp/gmp_5.0.2.bb +++ b/meta/recipes-support/gmp/gmp_5.0.2.bb @@ -2,11 +2,12 @@ require gmp.inc LICENSE="LGPLv3&GPLv3" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \ file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790" -PR = "r0" +PR = "r1" SRC_URI_append += "file://sh4-asmfix.patch \ file://use-includedir.patch " +export CC_FOR_BUILD = "${BUILD_CC}" SRC_URI[md5sum] = "0bbaedc82fb30315b06b1588b9077cd3" SRC_URI[sha256sum] = "dbc2db76fdd4e99f85d5e35aa378ed62c283e0d586b91bd8703aff75a7804c28" diff --git a/meta/recipes-support/hal/files/probe-video4linux.c.patch b/meta/recipes-support/hal/files/probe-video4linux.c.patch new file mode 100644 index 0000000000..0f8140be85 --- /dev/null +++ b/meta/recipes-support/hal/files/probe-video4linux.c.patch @@ -0,0 +1,60 @@ +Upstream-Status: Backport + +From ae13d96fa2a0612b6000f4b8f6ed9d3564035703 Mon Sep 17 00:00:00 2001 +From: Michael Biebl <biebl@debian.org> +Date: Sun, 10 Apr 2011 12:54:53 +0000 +Subject: Build hald-probe-video4linux on current kernels again + +The hald-probe-video4linux prober supports both v4l1 and v4l2. Support for v4l1 +has been removed from Linux kernel 2.6.38. Instead of disabling the prober +altogether, #ifdef the v4l1 parts when building on a newer kernel. + +Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com> +--- +(limited to 'hald/linux/probing/probe-video4linux.c') + +diff --git a/hald/linux/probing/probe-video4linux.c b/hald/linux/probing/probe-video4linux.c +index 7bc13e8..b055720 100644 +--- a/hald/linux/probing/probe-video4linux.c ++++ b/hald/linux/probing/probe-video4linux.c +@@ -30,7 +30,9 @@ + #include <sys/types.h> + #include <sys/time.h> + #include <sys/ioctl.h> ++#ifdef HAVE_LINUX_VIDEODEV_H + #include <linux/videodev.h> ++#endif + #include <linux/videodev2.h> + #include <errno.h> + #include <fcntl.h> +@@ -50,7 +52,9 @@ main (int argc, char *argv[]) + int ret = -1; + char *udi; + char *device_file; ++#ifdef HAVE_LINUX_VIDEODEV_H + struct video_capability v1cap; ++#endif + struct v4l2_capability v2cap; + LibHalContext *ctx = NULL; + LibHalChangeSet *cset; +@@ -107,7 +111,9 @@ main (int argc, char *argv[]) + LIBHAL_FREE_DBUS_ERROR (&error); + libhal_device_add_capability (ctx, udi, "video4linux.radio", &error); + } +- } else { ++ } ++#ifdef HAVE_LINUX_VIDEODEV_H ++ else { + HAL_DEBUG (("ioctl VIDIOC_QUERYCAP failed")); + + if (ioctl (fd, VIDIOCGCAP, &v1cap) == 0) { +@@ -134,6 +140,7 @@ main (int argc, char *argv[]) + HAL_DEBUG (("ioctl VIDIOCGCAP failed")); + } + } ++#endif + + LIBHAL_FREE_DBUS_ERROR (&error); + libhal_device_commit_changeset (ctx, cset, &error); +-- +cgit v0.9.0.2-2-gbebe diff --git a/meta/recipes-support/hal/hal-info.inc b/meta/recipes-support/hal/hal-info.inc index 183dd0ede5..d6743de9df 100644 --- a/meta/recipes-support/hal/hal-info.inc +++ b/meta/recipes-support/hal/hal-info.inc @@ -18,5 +18,4 @@ do_configure() { oe_runconf } -PACKAGE_ARCH = "all" FILES_${PN} += "${datadir}/hal/" diff --git a/meta/recipes-support/hal/hal-info_20091130.bb b/meta/recipes-support/hal/hal-info_20091130.bb index 4469904b1f..65d4d6b05b 100644 --- a/meta/recipes-support/hal/hal-info_20091130.bb +++ b/meta/recipes-support/hal/hal-info_20091130.bb @@ -1,4 +1,6 @@ require hal-info.inc +PR = "r1" + SRC_URI[md5sum] = "34375489a02a00b250fdc0b280be11b8" SRC_URI[sha256sum] = "3b5a90eaea4359977d36c808a19b3f08835345a258c68b9c6c080ad5ef875224" diff --git a/meta/recipes-support/hal/hal-info_git.bb b/meta/recipes-support/hal/hal-info_git.bb index 3fff5e0a7d..adcde9e88f 100644 --- a/meta/recipes-support/hal/hal-info_git.bb +++ b/meta/recipes-support/hal/hal-info_git.bb @@ -1,7 +1,7 @@ require hal-info.inc PV = "${SRCDATE}+git" -PR = "r0" +PR = "r1" SRC_URI = "git://anongit.freedesktop.org/hal-info/;protocol=git;rev=HAL_INFO_20091130" S = "${WORKDIR}/git" diff --git a/meta/recipes-support/hal/hal_0.5.14.bb b/meta/recipes-support/hal/hal_0.5.14.bb index aa67ae6232..858e68519f 100644 --- a/meta/recipes-support/hal/hal_0.5.14.bb +++ b/meta/recipes-support/hal/hal_0.5.14.bb @@ -1,6 +1,6 @@ require hal.inc -PR = "r4" +PR = "r5" EXTRA_OECONF += "--with-linux-input-header=${STAGING_INCDIR}/linux/input.h" EXTRA_OEMAKE += "-e 'udevrulesdir=$(sysconfdir)/udev/rules.d'" @@ -15,3 +15,5 @@ FILES_${PN} =+ "${bindir}/hal-disable-polling \ SRC_URI[md5sum] = "e9163df591a6f38f59fdbfe33e73bf20" SRC_URI[sha256sum] = "323aacfa52f12def3b0d1e76456e34f027c345adc344aad19a8cc0c59c1a8d02" + +SRC_URI += "file://probe-video4linux.c.patch" diff --git a/meta/recipes-support/libcap/libcap.inc b/meta/recipes-support/libcap/libcap.inc index 350653071e..184b58a3e0 100644 --- a/meta/recipes-support/libcap/libcap.inc +++ b/meta/recipes-support/libcap/libcap.inc @@ -21,9 +21,18 @@ do_configure() { sed -e 's,BUILD_CFLAGS ?=,BUILD_CFLAGS := $(BUILD_CFLAGS),' -i Make.Rules } -EXTRA_OEMAKE = "LIBATTR=yes PAM_CAP=${@base_contains('DISTRO_FEATURES', 'pam', 'yes', 'no', d)} INDENT= SYSTEM_HEADERS=${STAGING_INCDIR} RAISE_SETFCAP=no" -EXTRA_OEMAKE_virtclass-native = "LIBATTR=no PAM_CAP=no INDENT= " -EXTRA_OEMAKE += " lib=${@os.path.basename('${libdir}')}" +EXTRA_OEMAKE = " \ + LIBATTR=yes \ + PAM_CAP=${@base_contains('DISTRO_FEATURES', 'pam', 'yes', 'no', d)} \ + INDENT= SYSTEM_HEADERS=${STAGING_INCDIR} RAISE_SETFCAP=no \ + lib=${@os.path.basename('${libdir}')} \ +" +EXTRA_OEMAKE_virtclass-native = " \ + LIBATTR=no \ + PAM_CAP=no \ + INDENT= \ + lib=${@os.path.basename('${libdir}')} \ +" do_compile() { oe_runmake diff --git a/meta/recipes-support/libcap/libcap_2.22.bb b/meta/recipes-support/libcap/libcap_2.22.bb index a31ba3fadd..dd63d9e742 100644 --- a/meta/recipes-support/libcap/libcap_2.22.bb +++ b/meta/recipes-support/libcap/libcap_2.22.bb @@ -1,6 +1,6 @@ require libcap.inc -PR = "r1" +PR = "r2" SRC_URI[md5sum] = "ce64058bdb3f086ddbfca8ce6c919845" SRC_URI[sha256sum] = "73ebbd4877b5f69dd28b72098e510c5b318bc480f8201c4061ac98b78c04050f" diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc b/meta/recipes-support/libgcrypt/libgcrypt.inc index 989d5569bb..088cd34eff 100644 --- a/meta/recipes-support/libgcrypt/libgcrypt.inc +++ b/meta/recipes-support/libgcrypt/libgcrypt.inc @@ -28,3 +28,5 @@ ARM_INSTRUCTION_SET = "arm" # move libgcrypt-config into -dev package FILES_${PN} = "${libdir}/lib*.so.*" FILES_${PN}-dev += "${bindir} ${libdir}/pkgconfig/*.pc" + +BBCLASSEXTEND = "native" diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb b/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb index 0c10b47597..95f9e5602f 100644 --- a/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb +++ b/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb @@ -28,3 +28,5 @@ do_install_append() { # we don't have common lisp in OE rm -rf "${D}${datadir}/common-lisp/" } + +BBCLASSEXTEND = "native" diff --git a/meta/recipes-support/libnl/libnl-2.0/fix-makefile.patch b/meta/recipes-support/libnl/libnl-2.0/fix-makefile.patch deleted file mode 100644 index 3e88fbddc1..0000000000 --- a/meta/recipes-support/libnl/libnl-2.0/fix-makefile.patch +++ /dev/null @@ -1,32 +0,0 @@ -Upstream-Status: Pending - -12/03/2010 - -add explicit rules for header files generated by lex and yacc, -otherwise the build of lib/route/pktloc.c may fail in a parallel -environment. - -Signed-off-by: Qing He <qing.he@intel.com> - -12/06/2010 - -the dependency rule should really read pktloc.lo instead of -pktloc.$(OBJEXT), since it's in a libtool setup. - -Signed-off-by: Qing He <qing.he@intel.com> - -diff --git a/lib/Makefile.am b/lib/Makefile.am -index 92a916e..e8b8ef3 100644 ---- a/lib/Makefile.am -+++ b/lib/Makefile.am -@@ -35,6 +35,10 @@ route/pktloc_grammar.c: route/pktloc_grammar.l - route/pktloc_syntax.c: route/pktloc_syntax.y - $(YACC) -d $(YFLAGS) -o $@ $^ - -+route/pktloc.lo: route/pktloc_syntax.h route/pktloc_grammar.h -+route/pktloc_syntax.h: route/pktloc_syntax.c -+route/pktloc_grammar.h: route/pktloc_grammar.c -+ - libnl_route_la_LDFLAGS = -version-info 2:0:0 - libnl_route_la_LIBADD = libnl.la - libnl_route_la_SOURCES = \ diff --git a/meta/recipes-support/libnl/libnl-2.0/fix-pc-file.patch b/meta/recipes-support/libnl/libnl-2.0/fix-pc-file.patch new file mode 100644 index 0000000000..85afe8f751 --- /dev/null +++ b/meta/recipes-support/libnl/libnl-2.0/fix-pc-file.patch @@ -0,0 +1,17 @@ +Upstream-Status: Pending + +Some packages are asking only for libnl-2.0, but expects to get also +libnl-genl, libnl-nf libnl-route, easiest way to fix them is here. + +Signed-off-by: Martin Jansa <martin.jansa@gmail.com> +Index: libnl-2.0/libnl-2.0.pc.in +=================================================================== +--- libnl-2.0.orig/libnl-2.0.pc.in ++++ libnl-2.0/libnl-2.0.pc.in +@@ -6,5 +6,5 @@ + Name: libnl + Description: Convenience library for netlink sockets + Version: @PACKAGE_VERSION@ +-Libs: -L${libdir} -lnl ++Libs: -L${libdir} -lnl -lnl-genl -lnl-nf -lnl-route + Cflags: -I${includedir} diff --git a/meta/recipes-support/libnl/libnl-2.0/fix-pktloc_syntax_h-race.patch b/meta/recipes-support/libnl/libnl-2.0/fix-pktloc_syntax_h-race.patch new file mode 100644 index 0000000000..ea32e82b66 --- /dev/null +++ b/meta/recipes-support/libnl/libnl-2.0/fix-pktloc_syntax_h-race.patch @@ -0,0 +1,29 @@ +Upstream-Status: Inappropriate [configuration] + +libnl has progressed to 0.3.2 and there does not appear to be any +"make -j" issues with this build after my limited testing on that +newer version so we can assume this issue is fixed upstream + +Signed-off-by: Martin Jansa <martin.jansa@gmail.com> + +Index: libnl-2.0/lib/Makefile.am +=================================================================== +--- libnl-2.0.orig/lib/Makefile.am ++++ libnl-2.0/lib/Makefile.am +@@ -27,11 +27,16 @@ CLEANFILES = \ + route/pktloc_grammar.c route/pktloc_grammar.h \ + route/pktloc_syntax.c route/pktloc_syntax.h + ++BUILT_SOURCES = route/pktloc_syntax.h route/pktloc_grammar.h ++ + # Hack to avoid using ylwrap. It does not function correctly in combination + # with --header-file= ++route/pktloc.lo: route/pktloc_syntax.h route/pktloc_grammar.h ++route/pktloc_grammar.h: route/pktloc_grammar.c + route/pktloc_grammar.c: route/pktloc_grammar.l + $(LEX) --header-file=route/pktloc_grammar.h $(LFLAGS) -o $@ $^ + ++route/pktloc_syntax.h: route/pktloc_syntax.c + route/pktloc_syntax.c: route/pktloc_syntax.y + $(YACC) -d $(YFLAGS) -o $@ $^ + diff --git a/meta/recipes-support/libnl/libnl_2.0.bb b/meta/recipes-support/libnl/libnl_2.0.bb index 0dfcaf63a7..c96e7db2e9 100644 --- a/meta/recipes-support/libnl/libnl_2.0.bb +++ b/meta/recipes-support/libnl/libnl_2.0.bb @@ -6,15 +6,22 @@ LICENSE = "LGPLv2.1" LIC_FILES_CHKSUM = "file://COPYING;md5=2b41e13261a330ee784153ecbb6a82bc" DEPENDS = "flex-native bison-native" -PR = "r2" +PE = "1" +PR = "r6" -SRC_URI= "http://www.infradead.org/~tgr/libnl/files/${BPN}-${PV}.tar.gz \ - file://fix-makefile.patch \ - " +SRC_URI = "\ + http://www.infradead.org/~tgr/${BPN}/files/${BP}.tar.gz \ + file://fix-pktloc_syntax_h-race.patch \ + file://fix-pc-file.patch \ +" SRC_URI[md5sum] = "6aaf1e9802a17a7d702bb0638044ffa7" SRC_URI[sha256sum] = "5a40dc903d3ca1074da7424b908bec8ff16936484798c7e46e53e9db8bc87a9c" inherit autotools pkgconfig -LEAD_SONAME = "libnl.so" +PACKAGES =+ "${PN}-route ${PN}-nf ${PN}-genl ${PN}-cli" +FILES_${PN}-route = "${libdir}/libnl-route.so.*" +FILES_${PN}-nf = "${libdir}/libnl-nf.so.*" +FILES_${PN}-genl = "${libdir}/libnl-genl.so.*" +FILES_${PN}-cli = "${libdir}/libnl-cli.so.*" diff --git a/meta/recipes-support/libproxy/libproxy_0.4.6.bb b/meta/recipes-support/libproxy/libproxy_0.4.6.bb index d907c5576a..0fbe35e166 100644 --- a/meta/recipes-support/libproxy/libproxy_0.4.6.bb +++ b/meta/recipes-support/libproxy/libproxy_0.4.6.bb @@ -6,9 +6,10 @@ LICENSE = "LGPLv2.1+" LIC_FILES_CHKSUM = "file://COPYING;md5=7d7044444a7b1b116e8783edcdb44ff4 \ file://utils/proxy.c;beginline=1;endline=18;md5=55152a1006d7dafbef32baf9c30a99c0" - DEPENDS = "gconf" +PR = "r1" + SRC_URI = "http://libproxy.googlecode.com/files/libproxy-${PV}.tar.gz" SRC_URI[md5sum] = "199c6b120baf1f7258a55f38d5ec74f5" @@ -21,6 +22,7 @@ inherit cmake pkgconfig EXTRA_OECMAKE = "-DWITH_WEBKIT=no -DWITH_GNOME=yes -DWITH_KDE4=no \ -DWITH_PYTHON=no -DWITH_PERL=no -DWITH_MOZJS=no -DWITH_NM=no -DLIB_INSTALL_DIR=${libdir}" +FILES_${PN}-dev += "${datadir}/cmake" FILES_${PN}-dbg += "${libdir}/libproxy/${PV}/plugins/.debug/ ${libdir}/libproxy/${PV}/modules/.debug/" do_configure_prepend() { diff --git a/meta/recipes-support/libxslt/libxslt_1.1.26.bb b/meta/recipes-support/libxslt/libxslt_1.1.26.bb index 8cfce0a589..96bffc6231 100644 --- a/meta/recipes-support/libxslt/libxslt_1.1.26.bb +++ b/meta/recipes-support/libxslt/libxslt_1.1.26.bb @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0cd9a07afbeb24026c9b03aecfeba458" SECTION = "libs" DEPENDS = "libxml2" -PR = "r2" +PR = "r3" SRC_URI = "ftp://xmlsoft.org/libxslt//libxslt-${PV}.tar.gz \ file://pkgconfig_fix.patch" @@ -24,6 +24,6 @@ RPROVIDES_${PN}-bin += "${PN}-utils" RCONFLICTS_${PN}-bin += "${PN}-utils" RREPLACES_${PN}-bin += "${PN}-utils" -FILES_${PN}-dev += "${bindir}/xsltConf.sh" +FILES_${PN}-dev += "${libdir}/xsltConf.sh" BBCLASSEXTEND = "native" diff --git a/meta/recipes-support/sqlite/sqlite3.inc b/meta/recipes-support/sqlite/sqlite3.inc index 2a52a44175..ece35c54f4 100644 --- a/meta/recipes-support/sqlite/sqlite3.inc +++ b/meta/recipes-support/sqlite/sqlite3.inc @@ -20,7 +20,7 @@ export config_TARGET_LFLAGS = "${LDFLAGS}" PKGSUFFIX = "" PKGSUFFIX_virtclass-nativesdk = "-nativesdk" -PACKAGES = "lib${BPN}${PKGSUFFIX} lib${BPN}${PKGSUFFIX}-dev lib${BPN}${PKGSUFFIX}-doc ${PN} ${PN}-dbg" +PACKAGES = "lib${BPN}${PKGSUFFIX} lib${BPN}${PKGSUFFIX}-dev lib${BPN}${PKGSUFFIX}-doc ${PN}-dbg ${PN}" FILES_${PN} = "${bindir}/*" FILES_lib${BPN}${PKGSUFFIX} = "${libdir}/*.so.*" FILES_lib${BPN}${PKGSUFFIX}-dev = "${libdir}/*.a ${libdir}/*.la ${libdir}/*.so \ diff --git a/meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb b/meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb index 5651c071d1..fd037804ab 100644 --- a/meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb +++ b/meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=65f0a57ca6928710b418c094b357 SRC_URI = "http://www.sqlite.org/sqlite-autoconf-3070701.tar.gz" S = "${WORKDIR}/sqlite-autoconf-3070701" -PR = "r0" +PR = "r1" SRC_URI[md5sum] = "554026fe7fac47b1cf61c18d5fe43419" SRC_URI[sha256sum] = "7dcc36b25f7bcbe2938d0ea2baea5b706f0af93473d02a3f612d7ab39e386edf" diff --git a/meta/site/common-glibc b/meta/site/common-glibc index 9b74038d90..364ab67d78 100644 --- a/meta/site/common-glibc +++ b/meta/site/common-glibc @@ -25,6 +25,9 @@ clamav_av_have_in_port_t=${clamav_av_have_in_port_t=yes} clamav_av_have_in_addr_t=${clamav_av_have_in_addr_t=yes} ac_cv_func_mmap_fixed_mapped=${ac_cv_func_mmap_fixed_mapped=yes} +# coreutils +fu_cv_sys_stat_statfs2_bsize=${fu_cv_sys_stat_statfs2_bsize=yes} + # glib glib_cv_strlcpy=${glib_cv_strlcpy=no} ac_cv_func_printf_unix98=${ac_cv_func_printf_unix98=yes} diff --git a/meta/site/common-uclibc b/meta/site/common-uclibc index bdad0e9dc6..a264765e87 100644 --- a/meta/site/common-uclibc +++ b/meta/site/common-uclibc @@ -28,6 +28,9 @@ ac_cv_have_abstract_sockets=${ac_cv_have_abstract_sockets=yes} bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=no} bash_cv_sys_siglist=${bash_cv_sys_siglist=no} +# coreutils +fu_cv_sys_stat_statfs2_bsize=${fu_cv_sys_stat_statfs2_bsize=yes} + # va_copy and _va_copy ac_cv_va_copy=${ac_cv_va_copy=yes} ac_cv___va_copy=${ac_cv___va_copy=yes} diff --git a/meta/site/ix86-common b/meta/site/ix86-common index 512c9a0d52..e2796eb3b9 100644 --- a/meta/site/ix86-common +++ b/meta/site/ix86-common @@ -1,6 +1,6 @@ # general ac_cv_sizeof_char=${ac_cv_sizeof_char=1} -ac_cv_sizeof_unsigned_char=${ac_cv_sizeof_unsigned_int=1} +ac_cv_sizeof_unsigned_char=${ac_cv_sizeof_unsigned_char=1} ac_cv_sizeof_char_p=${ac_cv_sizeof_char_p=4} ac_cv_sizeof_unsigned_char_p=${ac_cv_sizeof_unsigned_char_p=4} ac_cv_sizeof_int=${ac_cv_sizeof_int=4} diff --git a/meta/site/powerpc64-linux b/meta/site/powerpc64-linux index 9430ea1e23..a49c717421 100644 --- a/meta/site/powerpc64-linux +++ b/meta/site/powerpc64-linux @@ -19,3 +19,16 @@ ac_cv_sizeof_unsigned_long_long_int=${ac_cv_sizeof_unsigned_long_long_int=8} ac_cv_sizeof_unsigned_short=${ac_cv_sizeof_unsigned_short=2} ac_cv_sizeof_unsigned_short_int=${ac_cv_sizeof_unsigned_short_int=2} ac_cv_sizeof_void_p=${ac_cv_sizeof_void_p=8} + +# screen +screen_cv_sys_bcopy_overlap=${screen_cv_sys_bcopy_overlap=no} +screen_cv_sys_memcpy_overlap=${screen_cv_sys_memcpy_overlap=no} +screen_cv_sys_memmove_overlap=${screen_cv_sys_memmove_overlap=no} +screen_cv_sys_fifo_broken_impl=${screen_cv_sys_fifo_broken_impl=yes} +screen_cv_sys_fifo_usable=${screen_cv_sys_fifo_usable=yes} +screen_cv_sys_select_broken_retval=${screen_cv_sys_select_broken_retval=no} +screen_cv_sys_sockets_nofs=${screen_cv_sys_sockets_nofs=no} +screen_cv_sys_sockets_usable=${screen_cv_sys_sockets_usable=yes} +screen_cv_sys_terminfo_used=${screen_cv_sys_terminfo_used=yes} + + diff --git a/meta/site/x86_64-linux b/meta/site/x86_64-linux index 3fa8f1eb05..a0a9362fb9 100644 --- a/meta/site/x86_64-linux +++ b/meta/site/x86_64-linux @@ -118,3 +118,6 @@ ac_cv_func___lshrdi3=no ac_cv_func___trampoline_setup=no ac_cv_func___ucmpdi2=no ac_cv_func__restgpr_14_x=no + +# cvs +cvs_cv_func_printf_ptr=${cvs_cv_func_printf_ptr=yes} diff --git a/scripts/bitbake b/scripts/bitbake index 587428c589..1c8d4ebe19 100755 --- a/scripts/bitbake +++ b/scripts/bitbake @@ -27,6 +27,15 @@ if [ "$py_v3_check" != "" ]; then exit 1 fi +# Similarly, we now have code that doesn't parse correctly with older +# versions of Python, and rather than fixing that and be eternally +# vigilant for any other new feature use, just check the version here. +py_v26_check=`python -c 'import sys; print sys.version_info >= (2,6,0)'` +if [ "$py_v26_check" != "True" ]; then + echo "BitBake requires Python 2.6 or later" + exit 1 +fi + needtar="1" TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4` float_test() { diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index 61ac18c14e..21b92b0f9e 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -70,5 +70,4 @@ unset BITBAKEDIR # Used by the runqemu script export BUILDDIR export PATH - -export BB_ENV_EXTRAWHITE="MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND" +export BB_ENV_EXTRAWHITE="MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND GIT_PROXY_IGNORE SOCKS5_PASSWD SOCKS5_USER" diff --git a/scripts/oe-setup-rpmrepo b/scripts/oe-setup-rpmrepo index 03372b6199..ea885f6325 100755 --- a/scripts/oe-setup-rpmrepo +++ b/scripts/oe-setup-rpmrepo @@ -17,9 +17,15 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +# Don't use TMPDIR from the external environment, it may be a distro +# variable pointing to /tmp (e.g. within X on OpenSUSE) +# Instead, use OE_TMPDIR for passing this in externally. +TMPDIR="$OE_TMPDIR" + function usage() { echo "Usage: $0 <rpm-dir>" - echo " <rpm-dir>: default is $TPMDIR/deploy/rpm" + echo " <rpm-dir>: default is $TMPDIR/deploy/rpm" } if [ $# -gt 1 ]; then @@ -29,19 +35,20 @@ fi setup_tmpdir() { if [ -z "$TMPDIR" ]; then - if [ "x$BUILDDIR" = "x" -o ! -d "$BUILDDIR/tmp" ]; then - # BUILDDIR unset, try and get TMPDIR from bitbake - type -P bitbake &>/dev/null || { - echo "In order for this script to dynamically infer paths"; - echo "to kernels or filesystem images, you either need"; - echo "bitbake in your PATH or to source oe-init-build-env"; - echo "before running this script" >&2; - exit 1; } - - # We have bitbake in PATH, get TMPDIR from bitbake - TMPDIR=`bitbake -e | grep TMPDIR=\" | cut -d '=' -f2 | cut -d '"' -f2` - else - TMPDIR=$BUILDDIR/tmp + # Try to get TMPDIR from bitbake + type -P bitbake &>/dev/null || { + echo "In order for this script to dynamically infer paths"; + echo "to kernels or filesystem images, you either need"; + echo "bitbake in your PATH or to source oe-init-build-env"; + echo "before running this script" >&2; + exit 1; } + + # We have bitbake in PATH, get TMPDIR from bitbake + TMPDIR=`bitbake -e | grep ^TMPDIR=\" | cut -d '=' -f2 | cut -d '"' -f2` + if [ -z "$TMPDIR" ]; then + echo "Error: this script needs to be run from your build directory," + echo "or you need to explicitly set TMPDIR in your environment" + exit 1 fi fi } diff --git a/scripts/qemuimage-testlib b/scripts/qemuimage-testlib index 9ffaa7c785..f52ac7bb86 100755 --- a/scripts/qemuimage-testlib +++ b/scripts/qemuimage-testlib @@ -83,7 +83,7 @@ Test_SCP() local src=$2 local des=$3 local tmpfile=`mktemp` - local timeout=60 + local time_out=60 local ret=0 # We use expect to interactive with target by ssh @@ -109,7 +109,7 @@ Test_SSH() shift local command=$@ local tmpfile=`mktemp` - local timeout=60 + local time_out=60 local ret=0 local exp_cmd=`cat << EOF eval spawn ssh -o UserKnownHostsFile=$tmpfile root@$ip_addr "$command" @@ -467,8 +467,8 @@ Test_Create_Qemu() export MACHINE=$QEMUARCH # Create Qemu in localhost VNC Port 1 - echo "Running xterm -display ${DISPLAY} -e 'TMPDIR=${TMPDIR} ${RUNQEMU} ${KERNEL} ${TEST_ROOTFS_IMAGE} && /bin/sleep 60' &" - xterm -display ${DISPLAY} -e "TMPDIR=${TMPDIR} ${RUNQEMU} ${KERNEL} ${TEST_ROOTFS_IMAGE} && /bin/sleep 60" & + echo "Running xterm -display ${DISPLAY} -e 'OE_TMPDIR=${OE_TMPDIR} ${RUNQEMU} ${KERNEL} ${TEST_ROOTFS_IMAGE} && /bin/sleep 60' &" + xterm -display ${DISPLAY} -e "OE_TMPDIR=${OE_TMPDIR} ${RUNQEMU} ${KERNEL} ${TEST_ROOTFS_IMAGE} && /bin/sleep 60" & # Get the pid of the xterm processor, which will be used in Test_Kill_Qemu PID=$! diff --git a/scripts/runqemu b/scripts/runqemu index 0f943b5fec..1e8121b321 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -55,6 +55,11 @@ SCRIPT_QEMU_OPT="" SCRIPT_QEMU_EXTRA_OPT="" SCRIPT_KERNEL_OPT="" +# Don't use TMPDIR from the external environment, it may be a distro +# variable pointing to /tmp (e.g. within X on OpenSUSE) +# Instead, use OE_TMPDIR for passing this in externally. +TMPDIR="$OE_TMPDIR" + # Determine whether the file is a kernel or QEMU image, and set the # appropriate variables process_filename() { @@ -189,6 +194,14 @@ while [ $i -le $# ]; do i=$((i + 1)) done +if [ ! -c /dev/net/tun ] ; then + echo "TUN control device /dev/net/tun is unavailable; you may need to enable TUN (e.g. sudo modprobe tun)" + exit 1 +elif [ ! -w /dev/net/tun ] ; then + echo "TUN control device /dev/net/tun is not writable, please fix (e.g. sudo chmod 666 /dev/net/tun)" + exit 1 +fi + YOCTO_KVM_WIKI="https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qemu" # Detect KVM configuration if [[ "x$KVM_ENABLED" == "xyes" ]]; then @@ -260,7 +273,7 @@ SPITZ_DEFAULT_FSTYPE=ext3 setup_tmpdir() { if [ -z "$TMPDIR" ]; then - # BUILDDIR unset, try and get TMPDIR from bitbake + # Try to get TMPDIR from bitbake type -P bitbake &>/dev/null || { echo "In order for this script to dynamically infer paths"; echo "to kernels or filesystem images, you either need"; diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs index fec288accd..f8213ba4ef 100755 --- a/scripts/runqemu-export-rootfs +++ b/scripts/runqemu-export-rootfs @@ -83,10 +83,12 @@ NFS_MOUNTPROG=$[ 21111 + $NFS_INSTANCE ] NFS_NFSPROG=$[ 11111 + $NFS_INSTANCE ] # NFS port number NFS_PORT=$[ 3049 + $NFS_INSTANCE ] +# mountd port number +MOUNT_PORT=$[ 3048 + $NFS_INSTANCE ] ## For debugging you would additionally add ## --debug all -MOUNTD_OPTS="--allow-non-root --mount-pid $MOUNTPID -f $EXPORTS --rmtab $RMTAB --prog $NFS_MOUNTPROG -r" +MOUNTD_OPTS="--allow-non-root --mount-pid $MOUNTPID -f $EXPORTS --rmtab $RMTAB --prog $NFS_MOUNTPROG -r -P $MOUNT_PORT" NFSD_OPTS="--allow-non-root --nfs-pid $NFSPID -f $EXPORTS --prog $NFS_NFSPROG -P $NFS_PORT -r" # Setup the exports file diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup index 870cb6bcb7..3bd9980ad0 100755 --- a/scripts/runqemu-ifup +++ b/scripts/runqemu-ifup @@ -94,7 +94,7 @@ if [ ! -x "$IPTABLES" ]; then fi n=$[ (`echo $TAP | sed 's/tap//'` * 2) + 1 ] -$IFCONFIG $TAP 192.168.7.$n +$IFCONFIG $TAP 192.168.7.$n netmask 255.255.255.255 dest=$[ (`echo $TAP | sed 's/tap//'` * 2) + 2 ] $ROUTE add -host 192.168.7.$dest $TAP diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal index ce3291f3a9..2968ed939c 100755 --- a/scripts/runqemu-internal +++ b/scripts/runqemu-internal @@ -258,21 +258,15 @@ fi if [ "$FSTYPE" = "nfs" ]; then NFS_SERVER="192.168.7.1" NFS_DIR=`echo $ROOTFS | sed 's/^[^:]*:\(.*\)/\1/'` - MOUNTD_PORT=$[ 21111 + $NFS_INSTANCE ] - NFSD_PORT=$[ 11111 + $NFS_INSTANCE ] - UNFS_OPTS="nfsvers=2,mountprog=$MOUNTD_PORT,nfsprog=$NFSD_PORT,udp" + MOUNTD_RPCPORT=$[ 21111 + $NFS_INSTANCE ] + NFSD_RPCPORT=$[ 11111 + $NFS_INSTANCE ] + NFSD_PORT=$[ 3049 + $NFS_INSTANCE ] + MOUNTD_PORT=$[ 3048 + $NFS_INSTANCE ] + UNFS_OPTS="nfsvers=2,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,port=$NFSD_PORT,mountport=$MOUNTD_PORT" PSEUDO_LOCALSTATEDIR=~/.runqemu-sdk/pseudo export PSEUDO_LOCALSTATEDIR - rpcbind_running=`ps ax | grep rpcbind | grep -v grep | wc -l` - portmap_running=`ps ax | grep portmap | grep -v grep | wc -l` - if [[ $rpcbind_running == 0 && $portmap_running == 0 ]]; then - echo "You need to be running either rpcbind or portmap to continue" - cleanup - return - fi - # Start the userspace NFS server echo "runqemu-export-rootfs restart $ROOTFS" runqemu-export-rootfs restart $ROOTFS |
