I am writing an image description which I want to append on multiple layers
a bsp layer, a security layer and an application layer.
in bsp: I have image.bb and image-dev.bb with
require image.bb
on the other layers I have image.bbappend and image-dev.bbappend
require image.bbappend
does causes the error:
ERROR: ParseError in .../sources/meta-application/recipes-core/images/image.bbappend: not a BitBake file
When I build image the packages in image.bb and all image.bbappend are present
When I build image-dev the stuff in image.bb, image-dev.bb and all the image-dev.bbapend is present Not the packages from image.bbappend
bitbake -e image-dev yields:
# $IMAGE_INSTALL [21 operations]
# set .../sources/poky/meta/conf/documentation.conf:212
# [doc] "Specifies the packages to install into an image. Image recipes set IMAGE_INSTALL to specify the packages to install into an image through image.bbclass."
# set .../sources/poky/meta/recipes-core/images/core-image-minimal.bb:3
# "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
# set? .../sources/poky/meta/classes/core-image.bbclass:70
# "${CORE_IMAGE_BASE_INSTALL}"
# set? .../sources/poky/meta/classes/image.bbclass:70
# ""
# set .../sources/poky/meta/classes/image.bbclass:71
# [type] "list"
# _append .../sources/meta-bsp/recipes-core/images/image.bb:32
...
# _append .../sources/meta-bsp/recipes-core/images/image-dev.bb:38
...
# _append .../sources/meta-application/recipes-core/images/image-dev.bbappend:24
...
# _append .../sources/meta-my-security/recipes-core/images/image-dev.bbappend:14
...
Any idea how to fully inherit/include the entire base image including all it's bbappends?!
Thank you!
Stefan
I managed to solve it with the following structure:
/meta-bsp/recipes-core/images/image.bb
... base packages
/meta-bsp/recipes-core/images/image-dev.bb
... development packages (like vim/htop/tree...)
/meta-application/recipes-core/images/image.inc
... application packages
/meta-application/recipes-core/images/image.bbappend
require image.inc
/meta-application/recipes-core/images/image-dev.bbappend
require image.inc
... application testing programms
/meta-my-security/recipes-core/images/image.inc
security packages
/meta-my-security/recipes-core/images/image.bbappend
require image.inc
/meta-my-security/recipes-core/images/image-dev.bbappend
require image.inc
.. security testing packages
Remove require image.bbappend from file image-dev.bbappend
There is no need to require image.bbappend in image-dev.bbappend. image.bb already contains configurations from image.bbappend file. so adding require image.bb in image-dev.bb file is sufficient
Related
let say i have a new yocto image call stargazer-cmd
what file should i edit so that every time i source poky/oe-init-env
it display as a build option to the user?
kj#kj-Aspire-V3-471G:~/stm32Yoctominimal$ source poky/oe-init-build-env build-mp1/
### Shell environment set up for builds. ###
You can now run 'bitbake <target>'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support
I wish to add stargazer-cmd on top of core-image-minimal, i am not sure what to google and what is the file i need to change.
Let me explain how to add a custom configuration to the OpenEmbedded build process.
First of all, here is the process that is done when running:
source poky/oe-init-build-env
The oe-init-build-env script initializes OEROOT variable to point to the location of the script itself.
The oe-init-build-env script sources another file $OEROOT/scripts/oe-buildenv-internal which will:
Check if OEROOT is set
Set BUILDDIR to your custom build directory name $1, or just build if you do not provide one
Set BBPATH to the poky/bitbake folder
Adds $BBPATH/bin and OEROOT/scripts to PATH (This will enable commands like bitbake and bitbake-layers ...)
Export BUILDDIR and PATH to the next file
The oe-init-build-env script continues by running the final build script with:
TEMPLATECONF="$TEMPLATECONF" $OEROOT/scripts/oe-setup-builddir
The oe-setup-builddir script will:
Check if BUILDDIR is set
Create the conf directory under $BUILDDIR
Sources a template file that will check if there is a TEMPLATECONF variable is set:
. $OEROOT/.templateconf
That file contains:
# Template settings
TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
it means that if TEMPLATECONF variable is not set, set it to meta-poky/conf, and that is where the default local.conf and bblayers.conf are coming from.
Copy $TEMPLATECONF to $BUILDDIR/conf/templateconf.cfg
Set some variables pointing to custom local.conf and bblayers.conf:
OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample"
OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
In the oe-setup-builddir there is a comment saying that TEMPLATECONF can point to a directory:
#
# $TEMPLATECONF can point to a directory for the template local.conf & bblayers.conf
#
Copy local.conf.sample and bblayers.conf.sample from TEMPLATECONF directory into BUIDDIR/conf:
cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf"
sed -e "s|##OEROOT##|$OEROOT|g" \
-e "s|##COREBASE##|$OEROOT|g" \
$OECORELAYERCONF > "$BUILDDIR/conf/bblayers.conf"
Finally it will print what is inside OECORENOTESCONF which points to TEMPLATECONF/conf-notes.txt:
[ ! -r "$OECORENOTESCONF" ] || cat $OECORENOTESCONF
and by default that is located under meta-poky/conf/conf-notes.txt:
### Shell environment set up for builds. ###
You can now run 'bitbake <target>'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86'
Other commonly useful commands are:
- 'devtool' and 'recipetool' handle common recipe tasks
- 'bitbake-layers' handles common layer tasks
- 'oe-pkgdata-util' handles common target package tasks
So, now, after understanding all of that, here is what you can do:
Create a custom template directory for your project, containing:
local.conf.sample
bblayers.conf.sample
conf-notes.txt
Do not forget to set the path to poky in bblayers.conf to ##OEROOT## as it will be set automatically by the build script.
Set your custom message in conf-notes.txt
Before any new build, just set TEMPLATECONF:
TEMPLATECONF="<path/to/template-directory>" source poky/oe-init-build-env <build_name>
Then, you will find a build with your custom local.conf and bblayers.conf with additional file conf/templateconf.cfg containing the path of TEMPLATECONF
conf/conf-notes.txt in your layer.
OECORENOTESCONF should point to the file.
A kernel module name galcore.ko is making my imx6slevk board hang while booting.
The path to this file is:
/lib/modules/4.9.88-imx_4.9.88_2.0.0_ga+g5e23f9d61147/extra/galcore.ko
on manually deleting this .ko file and flashng rootfs the board boots fine.
I'd like to modify the yyocto source to prevent this .ko file from auto loading.
I've tried adding
PACKAGE_EXCLUDE = "imx-gpu-viv"
and also
IMAGE_INSTALL_remove = "imx-gpu-viv"
into my fsl-image-validation-qt5.bb file but neither of them had any effect.
This is the bb file for autoloading of galcore
inherit module
require recipes-kernel/linux/linux-imx-src.inc
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
EXTRA_OEMAKE += "CONFIG_MXC_GPU_VIV=m"
KERNEL_MODULE_AUTOLOAD = ""
If I give "n" in the above OEMAKE path I get an error that says
ERROR: kernel-module-imx-gpu-viv-6.2.4.p1.2-r0 do_package: QA Issue: kernel-module-imx-gpu-viv: Files/directories were installed but not shipped in any package:
/lib
/lib/modules
/lib/modules/4.9.88-imx_4.9.88_2.0.0_ga+g5e23f9d61147
/lib/modules/4.9.88-imx_4.9.88_2.0.0_ga+g5e23f9d61147/extra
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install
How can I blacklist this kernel module or prevent it from autoloading?
To blacklist galcore kernel module, you should set following bitbake variables whereas in:
local.conf
virtual/kernel recipe bbappend
recipe providing galcore module bbappend
machine configuration
distro configuration
KERNEL_MODULE_PROBECONF += "galcore"
module_conf_galcore = "blacklist galcore"
It will create a /etc/modprobe.d/galcore.conf file with module_conf content.
See mega manual:
Kernel Module Autoloading
module_conf
KERNEL_MODULE_PROBECONF
My repository is set up similar to the following:
repo_base
- artwork
- app
- designsystem
- api
Since each of the other folders in the repo (e.g. app, api, designsystem) depend on artwork, I have symlinks in place when running locally. This is working fine, as the path for images in the designsystem subdirectory is something like ../../artwork. When you check out the repository, the entire tree is checked out, so the symlinks are pointing to the correct directory.
However, when I deploy with capistrano, I use :repo_tree to only deploy a portion of the overall monorepo. For example, the deploy.rb script for the designsystem folder looks like:
# config valid for current version and patch releases of Capistrano
lock "~> 3.11.0"
set :application, "designsystem"
set :repo_url, "git#gitlab.com:myuser/mymonorepo"
set :deploy_to, "/var/www/someplace.net/designsystem.someplace.net"
set :deploy_via, "remote_cache_with_project_root"
set :repo_tree, 'designsystem'
set :log_level, :error
before 'deploy:set_current_revision', 'deploy:buildMonolith'
The problem, of course, is that this only ends up deploying the designsystem subdirectory. Thus, the symlinks aren't valid, and are actually skipped in the building (buildMonolith step).
I'm wondering how I might go about having capistrano check out another subdirectory, artwork, and placing it somewhere in the repository source tree.
I was able to solve this by adding a capistrano task called assets.rb:
require 'pathname'
##
# Import assets from a top level monorepo directory into the current working
# directory.
#
# When you use :repo_tree to deploy a specific directory of a monorepo, but your
# asset repository is in a different directory, you need to check out this
# top-level directory and add it to the deployment path. For example, if your
# monorepo directory structure looks something like:
#
# - /app
# - src/
# - assets -> symlink to ../../assets
# - /assets
# - /api
#
# And you want to deploy /app, the symlink to the upper directory won't exist if
# capistrano is configured to use :repo_tree "app". In order to overcome this,
# this task checks out a specified piece of the larger monorepo (in this case,
# the assets directory), and places it in the deployment directory at a
# specified location.
#
# Configuration:
# In your deploy/<stage>.rb file, you will need to specify two variables:
# - :asset_path - The location within the deployment directory where the
# assets should be placed. Relative to the deployment working
# directory.
# - :asset_source - The location of the top-level asset folder in the
# monorepo. Relative to the top level of the monorepo (i.e.
# the directory that would be used as a deployment if
# :repo_tree was not specified).
#
# In the above example, you would specify:
#
# set :asset_path, "src/assets"
# set :asset_source, "assets"
#
namespace :deploy do
desc "Import assets from a top-level monorepo directory"
task :import_assets do
on roles(:all) do |host|
within repo_path do
final_asset_location = "#{release_path}/#{fetch(:asset_path)}"
asset_stat_result = capture "stat", "-t", "#{final_asset_location}"
asset_stat_result = asset_stat_result.split(" ")
if asset_stat_result[0] == "#{final_asset_location}"
info "Removing existing asset directory #{final_asset_location}..."
execute "rm", "-rf", "#{final_asset_location}"
end
source_dir = Pathname.new(final_asset_location).parent.to_s
info "Importing assets to #{source_dir}/#{fetch(:asset_source)}"
execute "GIT_WORK_TREE=#{source_dir}", :git, "checkout", "#{fetch(:branch)}", "--", "#{fetch(:asset_source)}"
info "Moving asset directory #{source_dir}/#{fetch(:asset_source)} to #{final_asset_location}..."
execute :mv, "#{source_dir}/#{fetch(:asset_source)}", "#{final_asset_location}"
end
end
end
end
It would be nice if I could somehow link into the git scm plugin, rather than calling git from the command line directly.
I'm trying to add auditd to Yocto linux.
I added the selinux layer and it's dependent layers: openembedded-core and meta-virtualization.
I added the layers to bblayers.conf.
I added DISTRO_FEATURES_append = " acl xattr pam selinux"
and PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls" to the local.conf file.
After building (by using bitbake core-image-base) and running the qemu, the kauditd process is running, but all user-space tools are not.
The /etc/audit folder is not exist ,non of the audit's config files exists (audit.rules) and no user-space audit process is running.
In the layer's info it is declared - "User space tools for kernel auditing".
What I am missing?
Thanks.
I think I found something that will answer your question: If you know what an example binary or library you expect to be in the target image, you can find what recipe the executable is in, and then add that package to the image.
Start with the name of a binary or library you expect to be in the image and run the following. For me, I am using a CAN bus executable called candump. I wonder what recipe it's in? To find out, I issue:
devtool search candump
Which returns:
can-utils
If nothing is returned, I'd double check your conf/bblayers.conf so that the layer you think it may be in is actually being seen by your build system. If you are unsure, take a look at the link below which points to OpenEmbedded which has a handy search utility for packages.
After you find the recipe, you can then include that recipe into your build.
Here is a good reference in doing what I think you're asking on the OpenEmbedded website:
https://wiki.yoctoproject.org/wiki/Cookbook:Example:Adding_packages_to_your_OS_image
I just added auditd to my system. This is what I did.
First I got the repository checked out.
cd /path/to/yocto
git clone git://git.yoctoproject.org/meta-selinux
cd meta-selinux
# checkout the branch matching the Yocto release you are on
git checkout thud
Then I added auditd to my build.
cd /path/to/build
bitbake-layers add-layer /path/to/yocto/meta-selinux
cat >> conf/local.conf <<'END'
IMAGE_INSTALL_append = " auditd"
END
bitbake my_normal_image_target
Even though the Yocto recipe is called audit, the package name is auditd.
Of course, auditd without selinux is useless but it did attempt to run (journalctl -u auditd) and /etc/audit exists.
FWIW: To get auditd to a point where it reports say, login success/failure, I had to do a few more things. I'm not just adding it to a standard Yocto image, but to a custom image and custom machine. I'm already using systemd so I didn't have to change that (the layer seems to indicate it's required?). My local.conf looked like this.
# enable selinux
DISTRO_FEATURES_append = " acl xattr pam selinux"
# set the policy
PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"
# install selinux packages and auditd
IMAGE_INSTALL_append = " packagegroup-core-selinux auditd"
# tell the kernel to enable selinux (non-enforcing) and audting
APPEND_append = " selinux=1 enforcing=0 audit=1"
I also had to change linux-yocto_selinux.inc to load selinux.cfg later. Probably layer/recipe ordering could have solved this too?
-SRC_URI += "${#bb.utils.contains('DISTRO_FEATURES', 'selinux', 'file://selinux.cfg', '', d)}"
+SRC_URI_append = "${#bb.utils.contains('DISTRO_FEATURES', 'selinux', 'file://selinux.cfg', '', d)}"
With all that in place, I see audit logs in my journal.
I am developing a Swift 2 project which includes many CocoaPods that work and am struggling to create a podspec file for this OrderedDictionary class from GitHub since the author didn't create a Podfile. I ran:
pod spec create "OrderedDictionary|https://github.com/lukaskubanek/OrderedDictionary"
which created OrderedDictionary.podspec in the root of my project directory:
#
# Be sure to run `pod spec lint OrderedDictionary.podspec' to ensure this is a
# valid spec and to remove all comments including this before submitting the spec.
#
# To learn more about Podspec attributes see http://docs.cocoapods.org/specification.html
# To see working Podspecs in the CocoaPods repo see https://github.com/CocoaPods/Specs/
#
Pod::Spec.new do |s|
# ――― Spec Metadata ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# These will help people to find your library, and whilst it
# can feel like a chore to fill in it's definitely to your advantage. The
# summary should be tweet-length, and the description more in depth.
#
s.name = "OrderedDictionary"
s.version = "0.5"
s.summary = "An implementation of OrderedDictionary in Swift"
# This description is used to generate tags and improve search results.
# * Think: What does it do? Why did you write it? What is the focus?
# * Try to keep it short, snappy and to the point.
# * Write the description between the DESC delimiters below.
# * Finally, don't worry about the indent, CocoaPods strips it!
s.description = "This is a lightweight implementation of an ordered dictionary data structure in Swift packed into a µframework."
s.homepage = "https://github.com/lukaskubanek/OrderedDictionary"
# s.screenshots = "www.example.com/screenshots_1.gif", "www.example.com/screenshots_2.gif"
# ――― Spec License ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Licensing your code is important. See http://choosealicense.com for more info.
# CocoaPods will detect a license file if there is a named LICENSE*
# Popular ones are 'MIT', 'BSD' and 'Apache License, Version 2.0'.
#
s.license = "MIT"
# s.license = { :type => "MIT", :file => "LICENSE.md" }
# ――― Author Metadata ――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Specify the authors of the library, with email addresses. Email addresses
# of the authors are extracted from the SCM log. E.g. $ git log. CocoaPods also
# accepts just a name if you'd rather not provide an email address.
#
# Specify a social_media_url where others can refer to, for example a twitter
# profile URL.
#
s.author = { "Lukas Kubanek" => "lukas.kubanek#me.com" }
# Or just: s.author = "Lukas Kubanek"
# s.authors = { "Lukas Kubanek" => "lukas.kubanek#me.com" }
# s.social_media_url = "http://twitter.com/Lukas Kubanek"
# ――― Platform Specifics ――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# If this Pod runs only on iOS or OS X, then specify the platform and
# the deployment target. You can optionally include the target after the platform.
#
# s.platform = :ios
s.platform = :ios, "8.0"
# When using multiple platforms
s.ios.deployment_target = "8.0"
# s.osx.deployment_target = "10.7"
# s.watchos.deployment_target = "2.0"
# s.tvos.deployment_target = "9.0"
# ――― Source Location ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Specify the location from where the source should be retrieved.
# Supports git, hg, bzr, svn and HTTP.
#
s.source = { :git => "https://github.com/lukaskubanek/OrderedDictionary.git", :tag => "v0.5" }
# ――― Source Code ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# CocoaPods is smart about how it includes source code. For source files
# giving a folder will include any swift, h, m, mm, c & cpp files.
# For header files it will include any header in the folder.
# Not including the public_header_files will make all headers public.
#
s.source_files = "Sources"
#s.exclude_files = "Classes/Exclude"
# s.public_header_files = "Classes/**/*.h"
# ――― Resources ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# A list of resources included with the Pod. These are copied into the
# target bundle with a build phase script. Anything else will be cleaned.
# You can preserve files from being cleaned, please don't preserve
# non-essential files like tests, examples and documentation.
#
# s.resource = "icon.png"
# s.resources = "Resources/*.png"
# s.preserve_paths = "FilesToSave", "MoreFilesToSave"
# ――― Project Linking ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# Link your library with frameworks, or libraries. Libraries do not include
# the lib prefix of their name.
#
# s.framework = "SomeFramework"
# s.frameworks = "SomeFramework", "AnotherFramework"
# s.library = "iconv"
# s.libraries = "iconv", "xml2"
# ――― Project Settings ――――――――――――――――――――――――――――――――――――――――――――――――――――――――― #
#
# If your library depends on compiler flags you can set them in the xcconfig hash
# where they will only apply to your library. If you depend on other Podspecs
# you can include multiple dependencies to ensure it works.
# s.requires_arc = true
# s.xcconfig = { "HEADER_SEARCH_PATHS" => "$(SDKROOT)/usr/include/libxml2" }
# s.dependency "JSONKit", "~> 1.4"
end
next to my Podfile:
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
use_frameworks!
pod 'OrderedDictionary', :podspec => "OrderedDictionary.podspec"
I ran:
pod cache clean OrderedDictionary && pod install
which created a Pods/OrderedDictionary group under the Pods project.
Unfortunately the group is empty, so the project fails to build at:
import OrderedDictionary
error: No such module 'OrderedDictionary'
Linting passes:
pod spec lint OrderedDictionary.podspec --verbose
For the life of me I can't get OrderedDictionary.swift and OrderedDictionary.h to copy into the pod's group in the project.
The weird thing is that I did see OrderedDictionary.h appear in the group once but couldn't get it to happen again. I'm concerned that CocoaPods might not be idempotent, but could be overlooking something obvious. Thanks for any help you can provide.
Xcode 7.2.1 (7C1002), OS X 10.10.5 (14F27), CocoaPods 0.39.0
Answering my own question based on IvanRublev's comment. I tried my podspec in this IceCreamShop CocoaPods swift example and then after it worked there, it worked in my original project.
Reproduction steps:
After I wrote this question last night, I bit the bullet and downloaded the zip of the OrderedDictionary GitHub project, expanded it to the root level of my project directory, moved my podspec inside it, and changed my Podfile to say:
pod 'OrderedDictionary', :path => "OrderedDictionary"
That allowed me to use it as a development pod, and I saw OrderedDictionary.swift and OrderedDictionary.h copied into the pod's group.
Today after I got IceCreamShop to work, I removed the OrderedDictionary directory from my project directory, moved my podspec back to the root level of my project directory, and changed the Podfile back to:
pod 'OrderedDictionary', :podspec => "OrderedDictionary.podspec"
The pod now worked, even though I didn't change anything.
I believe this may be a caching issue in CocoaPods, causing it to be inconsistent for one of the following reasons:
Being nontransparent, where issues like the subproject failing to build or a process being terminated leave the cache in an inconsistent state that allow us to detect the presence of the cache by its malfunction.
Not being invalidated correctly, so once it found files in my project dir, it somehow remembered them and was able to include them after they were removed.
Loads and stores behaving differently depending on where they are performed, allowing side effects to affect future loads and stores.
Having temporal issues where loads and stores are nondeterministic because timeouts take priority over the source of truth.
A cosmic ray from a distant galaxy flipping a bit in the cache causing my wave state to collapse into the reality where I spent hours chasing a bug instead of the one where I never knew the bug existed.
I like CocoaPods and realize this is all a bit tongue in cheek, but caching issues often have a detrimental impact on productivity and I would recommend that all projects have an option to disable their cache as well as have it run an internal consistency check every time it's used.
Here are some commands that might help someone experiencing similar problems:
sudo rm -rf ~/Library/Caches/CocoaPods/
sudo rm -rf ~/.cocoapods/repos/master/
sudo rm -rf Pods/
pod install