Skip to content

Instantly share code, notes, and snippets.

@sysarcher
Last active March 8, 2017 15:00
Show Gist options
  • Save sysarcher/cdac935fab6175aac9734604f04ccbc3 to your computer and use it in GitHub Desktop.
Save sysarcher/cdac935fab6175aac9734604f04ccbc3 to your computer and use it in GitHub Desktop.
local.conf for standard ostro-os build (tested on Intel Galileo)
#
# This file is your local configuration file and is where all local user settings
# are placed. The comments in this file give some guide to the options a new user
# to the system might want to change but pretty much any configuration option can
# be set in this file.
#
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
# variable as required.
#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of several hardware platforms that are supported:
#
# For MinnowBoard and Gigabyte GB-BXBT-3825:
#MACHINE ?= "intel-corei7-64"
#
# For Intel Galileo Gen 2:
MACHINE ?= "intel-quark"
#
# For Intel Edison:
#MACHINE ?= "edison"
#
# For BeagleBone Black:
#MACHINE ?= "beaglebone"
#
# This sets the default machine to be "intel-corei7-64" if no other machine is selected:
# MACHINE ??= "intel-corei7-64"
#
# Image formats
#
# You can customize the image format generated by bitbake by setting the OSTRO_VM_IMAGE_TYPES
# variable to any combination of the following: "dsk dsk.xz dsk.zip dsk.ova". In order to
# generate a bmap file that can be used by bmaptool, you need to add "dsk.bmap" to the list.
# It will also trigger the creation of corresponding symlinks. The default value is set in
# meta-ostro/classes/ostro-image.bbclass
#
OSTRO_VM_IMAGE_TYPES = "dsk.xz dsk.ova"
#
# Where to place downloads
#
# During a first build the system will download many different source code tarballs
# from various upstream projects. This can take a while, particularly if your network
# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build directory.
#
#DL_DIR ?= "${TOPDIR}/downloads"
#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"
#
# Default policy config
#
# The distribution setting controls which policy settings are used as defaults.
# The default value is fine for general Yocto project use, at least initially.
# Ultimately when creating custom policy, people will likely end up subclassing
# these defaults.
#
DISTRO ?= "ostro"
#
# Package Management configuration
#
# This variable lists which packaging formats to enable. Multiple package backends
# can be enabled at once and the first item listed in the variable will be used
# to generate the root filesystems.
# Options are:
# - 'package_deb' for debian style deb files
# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
# - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# We default to ipk because it is faster/smaller and good enough for
# image creation. On-device package management is disabled by default
# and thus the additional features offered for that by rpm/deb do not
# matter.
PACKAGE_CLASSES ?= "package_ipk"
#
# SDK/ADT target architecture
#
# This variable specifies the architecture to build SDK/ADT items for and means
# you can build the SDK packages for architectures other than the machine you are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686 and x86_64
#SDKMACHINE ?= "i686"
#
# Extra image configuration defaults
#
# The OSTRO_IMAGE_EXTRA_FEATURES variable allows extra packages to be added to the
# generated images. The variable can contain the following options:
# "dbg-pkgs" - add -dbg packages for all installed packages
# (adds symbol information for debugging/profiling)
# "dev-pkgs" - add -dev packages for all installed packages
# (useful if you want to develop against libs in the image)
# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
# (useful if you want to run the package test suites)
# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
# "tools-debug" - add debugging tools (gdb, strace)
# "tools-profile" - add profiling tools (oprofile, exmap, lttng, valgrind)
# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
# "debug-tweaks" - make an image suitable for development
# e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass, meta/classes/core-image.bbclass and
# meta-ostro/recipes-images/images/ostro-image.bb for more details.
#
# This variable is a derivative of the Yocto project EXTRA_IMAGE_FEATURES variable.
# We do not recommend to use EXTRA_IMAGE_FEATURES as it will also add these packages
# to the ostro-initramfs image which is most likely not the desired outcome.
#
# To use this variable, uncomment the following line and set it to what you want:
OSTRO_IMAGE_EXTRA_FEATURES = "dev-pkgs tools-sdk debug-tweaks"
#OSTRO_IMAGE_EXTRA_FEATURES += " dev-pkgs tools-sdk debug-tweaks "
# By default, the root account has no password set and thus cannot
# be logged into from outside. Local root access can be enabled
# as described in doc/howtos/building-images.rst.
#
# To enable access as root via ssh, the recommended approach for
# personal development images is to install an authorized ssh key
# as part of image creation, by setting OSTRO_ROOT_AUTHORIZED_KEYS
# in local.conf. Its content will be installed as ~root/.ssh/authorized_keys.
#
#OSTRO_ROOT_AUTHORIZED_KEYS = "ssh-rsa AAA...== john@example.com\nssh-dss AA...FPaQ== joan@example.com"
OSTRO_ROOT_AUTHORIZED_KEYS = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDlyRlqgJYkzgvorMRAaD21X2fX3da4+rLj0cV4631Rr3uZe2GoiNOTvc9k9DetdzRnhsGRPpxFHxdHwTpiHkvKS46bqa4x9PepV7ZSdZEOagWNYZCqx1eXlJHrRXk434duHbwTh4aJkRFd6HAyt63KZ2RNL0f6B7pUhMK/ISJhHBst8GxQ9b7U8QK2jF+XgUpfuIwISBShhIakYOTFxKfAfUycF+7iQfK2bdoIEmZKcYTL3DHn8sZIq2goHq7HaBTJhLVDVClGpUBhNNiWfbqM8/TnvacIoX+l70TwL6+yYQVUDBC+xTk29SVHaqb8XJtvYzlinS48MQ0hzC2zHd3v taimoor@QTDEV-2"
# When using ssh to access such a developer image, ssh will typically
# complain about the ssh host key because it gets re-created anew on
# the device the first time ssh is used. To avoid this, one can
# disable this check when invoking ssh:
#
# ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@<ip-os-ostro-device>
#
# On devices with little entropy, generating the ssh host key can take
# some time. This can be avoided by copying a generated host key off the
# device and having it copied into the image during the next image build.
#
# In this example, the dropbear_rsa_host_key was copied into the conf
# directory of the build directory. If it does not exist there yet, the
# ROOTFS_DEBUG_FILES entry will be silently ignored, so it is okay to set
# this in local.conf before placing the file there.
#
#INHERIT += "rootfsdebugfiles"
#ROOTFS_DEBUG_FILES += "${TOPDIR}/conf/dropbear_rsa_host_key ${IMAGE_ROOTFS}/etc/dropbear/dropbear_rsa_host_key ;"
#
# Additional image features
#
# The following is a list of additional classes to use when building images which
# enable extra features. Some available options which can be included in this variable
# are:
# - 'buildstats' collect build statistics
# - 'image-mklibs' to reduce shared library files size for an image
# - 'image-prelink' in order to prelink the filesystem image
# - 'image-swab' to perform host system intrusion detection
# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs"
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to do this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than one parallel
# process may require the user's attention. The default is iterate over the available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail instead):
PATCHRESOLVE = "noop"
#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that 1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
# of the build. The reason for this is that running completely out of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
BB_DISKMON_DIRS ?= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"
#
# Ostro OS recomended way is to use SSTATE cache produced by Ostro Project CI
# during official builds:
SSTATE_MIRRORS ?= "file://.* http://download.ostroproject.org/sstate/ostro-os/PATH"
# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "5"
#
# ISAFW: https://github.com/01org/isafw
# For details, see meta-security-isafw/README.md
#
# Note: at the moment it's not ready to be enabled by default
# This class lacks fine tuning of plugins, thus some plugins
# can produce quite high load on developer's system or might
# require special network configurations (e.g. proxy setup)
#
#INHERIT += "isafw"
# By default, only recipes explicitly declared to be okay for building Ostro OS
# are allowed to be built. Adding or depending on anything else triggers a
# message saying "The following unsupported recipes are required for the build"
# and aborts. See doc/howtows/building-images.rst for more information.
#SUPPORTED_RECIPES_CHECK = "fatal"
# Uncomment the following line to disable the check:
#SUPPORTED_RECIPES_CHECK = ""
#
# Alternatively, uncomment the following line to make it a non-fatal warning:
SUPPORTED_RECIPES_CHECK = "warn"
# Ostro OS does not package source code in dbg packages because our
# images include valgrind, and valgrind depends on the glibc dbg
# package. Including source code in dbg packages would therefore make
# the images larger than they normally need to be.
#
# If you need source code packaged and installed on images, comment out
# the following line.
PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
# An explicit choice must be made between building Ostro OS
# development images and production images. See
# doc/howtows/building-images.rst for further instructions.
# Ostro OS development images get built when uncommenting the
# following line. Do not do this in production! The resulting images
# are not secure.
#
require conf/distro/include/ostro-os-development.inc
# When building production images, configure IMA signing
# as described in meta-integrity/README.md if IMA is enabled
# and uncomment the following line.
#
#require conf/distro/include/ostro-os-production.inc
# systemd-bootchart is a useful tool to analyze and optimize a system
# boot time. The tool is available in Ostro and needs to be activated
# by a kernel command-line parameter which requires to build a new
# image. This tool also requires some kernel configurations to be active,
# specifically CONFIG_DEBUG_KERNEL and CONFIG_SCHEDSTATS.
#
# To use systemd-bootchart with the intel-corei7-64 or intel-quark machine
# uncomment the two lines below. Other MACHINEs that use u-boot (such as
# edison and beaglebone) use a different mechanism to modify the kernel
# command-line parameter, this is not covered here. The bootchart graphs
# will be available in /run/log/.
#
#APPEND_append = " init=/lib/systemd/systemd-bootchart"
#SRC_URI_append_pn-linux-yocto = " file://bootchart.cfg"
#
# Misc configuration
#
# Remove the old image from the deploy directory before the new
# one gets created. This is useful to save disk space.
RM_OLD_IMAGE = "1"
# SUPPORTED_RECIPES_CHECK = ""
# IMAGE_INSTALL_append = " python python-dev python-core python-pip python-py \
# gcc g++ binutils libgcc libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev \
# autoconf automake \
# "
#EXTRA_IMAGE_FEATURES =+ " dev-pkgs tools-sdk tools-debug"
OSTRO_IMAGE_EXTRA_INSTALL += "nano mosquitto opkg zeromq "
OSTRO_IMAGE_EXTRA_INSTALL += "python python3 python-pip python3-pip python3-dbus python3-pygobject \
python3-setuptools python3-multiprocessing python3-asyncio \
python-setuptools python-multiprocessing python-async python-pyzmq "
OSTRO_IMAGE_EXTRA_INSTALL += "util-linux-getopt"
OSTRO_IMAGE_EXTRA_INSTALL += "openjdk-8"
# bundle updates
#OSTRO_IMAGE_INSTALL_REFERENCE += "sudo"
#SWUPD_BUNDLES += "sudo_bundle"
#BUNDLE_CONTENTS[sudo_bundle] = "nano mosquitto opkg python3 python3-pip"
#SWUPD_IMAGES += "\
# pre_installed_content \
#"
#SWUPD_IMAGES[pre_installed_content]="\
# sudo_bundle \
#"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment