I have multiple variants for the same (custom) software. A few variants support different hardware platforms and other wariants support the same hardware platform but with different feature-set. For example I have:
mysoftware.bb (basic version)
mysoftware-qt.bb (basic + qt support)
mysoftware-lic.bb (basic + license support)
mysoftware-qt-lic.bb (basic + license + qt support)
My plan was to add PROVIDES = "mysoftware" to all of these recipes and PREFERRED_PROVIDER_mysoftware = "mysoftware-qt" to my machine conf file.
In my image recipe I wanted to add:
IMAGE_INSTALL += "mysoftware"
Many errors came up... like I had to set RPROVIDES_${PN} = "mysoftware" in every recipe and had to set SSTATE_DUPWHITELIST = "/" in those recipes. (and still not working...)
My question: is there a standard way to achieve this? or is this a bad practice? This seems to be a decent approach for me.
What I wanted to do in the end is:
IMAGE_INSTALL = "... mysoftware" and this will install the appropriate variant and I don't have to do like:
IMAGE_INSTALL_xhw = "... mysoftware-x"
IMAGE_INSTALL_yhw = "... mysoftware-y"
and for those very limited number of times when I have to change from mysoftware to mysoftware-qt I can install it with a package manager (apt in my case):
apt install mysoftware-x-qt
and as a result the conflicting mysoftware-x would be removed and mysoftware-x-qt would be installed easily.
Inside your recipe mysoftware-qt.bb add:
PROVIDES = "virtual/mysoftware"
RPROVIDES_${PN} = "virtual/mysoftware"
Inside your machine.conf add :
PREFERRED_PROVIDER_virtual/mysoftware = "mysoftware-qt
finally add IMAGE_INSTALL += "mysoftware" inside your image recipe
Related
I have two similar boards. I want to write a recipe for each of them. But they will have different kernel patches.How to do it better? Or Should I add new machines to the build?
I added my-machine to mylayer/local.conf
MACHINEOVERRIDES = "imx8qmmek:my-machine"
I created mylayer/recipex-kernel/linux/linux-imx_%.bbappend with my-patch:
SRC_URI_imx8qmmek += " file://0001-add-modified-dts.patch "
SRC_URI_imx8qmmek += " file://0002-EP4668-wifi-bt-modified-dts.patch "
SRC_URI_imx8qmmek += " file://0003-EP4822-enable-USB3-hub.patch "
SRC_URI_my-machine += " file://0004-EP4827-comment-usdhc3.tcu.patch "
SRC_URI_imx8qmmek += " file://EP4133_added_BRCM-PCIE.cfg"
do_configure_append_imx8qmmek() {
bbnote "adding BRCM-PCIE configuration ${PN}"
cat ../*.cfg >> ${B}/.config
}
And I run command:
MACHINE="my-machine" bitbake -c clean linux-imx
But a terminal outputed the error:
WARNING: Layer meta-mylayer should set LAYERSERIES_COMPAT_mylayer in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer meta-mylayer should set LAYERSERIES_COMPAT_meta-mylayer in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: You have included the meta-gnome layer, but 'x11' has not been enabled in your DISTRO_FEATURES. Some bbappend files may not take effect. See the meta-gnome README for details on enabling meta-gnome support.
WARNING: Host distribution "ubuntu-18.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
MACHINE=my-machine is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file.
Similar != identical. If they are indeed slightly different, then two machines is the way to go. If they are sufficiently similar (to be determined by yourself :) ), different distros is also an option. All depends on how different the machines are and how different the final images should be (might need two machines or two distros or both).
If you have two similar machines but need two machine configuration files, put most of the common code into an .inc required by both machines. Don't forget to put a MACHINEOVERRIDES somewhere in that inc file with a name that will make sense for both machines (e.g., if you have rpi3-lcd and rpi3-iot, have an rpi3-common.inc with rpi3-common added to MACHINEOVERRIDES). This will make it possible to use VAR_rpi3-common in recipes that have patches or machine specific stuff in your recipes to apply to both without needing VAR_rpi3-lcd AND VAR_rpi3-iot.
I have a module, built with Dist::Zilla. I have Dist::Zilla set up to automatically push changes out to my GitHub repo. Works great when the repo is private.
However, as soon as I make the repo public, I start getting errors during the build process. Specifically, these lines in the dist.ini
[Bugtracker]
web = http://github.com/myaccount/%s/issues
If I comment out these lines, it works. With these lines left in, I get an error:
Duplication of element resources.bugtracker.web at /Users/me/perl5/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.4/Dist/Zilla.pm line 595.
OK, so fine, I comment out the lines. However, another problem crops up. The version number of my builds no longer autoincrements and is stuck at the same number every time I try to release a build.
Is there some configuration setting I need to change with Dist::Zilla so it will play nice with public github repos? Here is the full dist.ini file:
name = Module-Test
author = me
license = Perl_5
copyright_holder = Me
copyright_year = 2018
[Repository]
;[Bugtracker]
;web = http://github.com/sdondley/%s/issues
[Git::NextVersion]
[GitHub::Meta]
[PodVersion]
[PkgVersion]
[NextRelease]
[Run::AfterRelease]
run = mv Changes tmp && cp %n-%v/Changes Changes
[InstallGuide]
[PodWeaver]
[ReadmeAnyFromPod]
type = markdown
location = root
phase = release
[Git::Check]
[Git::Commit]
allow_dirty = README.mkdn
allow_dirty = Changes
allow_dirty = INSTALL
[Git::Tag]
[Git::Push]
[Run::AfterRelease / MyAppAfter]
run = mv tmp/Changes Changes
[GatherDir]
[AutoPrereqs]
[PruneCruft]
[PruneFiles]
filename = weaver.ini
filename = README.mkdn
filename = dist.ini
filename = .gitignore
[ManifestSkip]
[MetaYAML]
[License]
[Readme]
[ExtraTests]
[ExecDir]
[ShareDir]
[MakeMaker]
[Manifest]
[TestRelease]
[FakeRelease]
Your [Bugtracker] entry leads to duplication because you are also setting the bugtracker through [GitHub::Meta]. Choose one or the other.
As for version number management, note that [Git::NextVersion] is based on your git tags. Make sure that these tags are present in your local repository and have the correct format. That plugin uses a command line invocation similar to this to obtain all tags:
git rev-list --simplify-by-decoration --pretty=%d HEAD | grep -oE 'tag: [^,)\s]+'
Public GitHub repos should not be a problem for Dist::Zilla – this is exactly the setup most dzil distros use anyway. But interactions between multiple plugins can lead to hard to track down bugs, especially since the order of plugins is important. It can help to organize your plugins by the phase in which they run, and to test whether the problem persists after removing optional plugins. It also tends to be better to start with a simple dist.ini and add plugins as pain points in your development process become apparent.
In the book "Embedded Linux Systems with the Yocto Project", Chapter 4 contains a sample called "HelloWorld - BitBake style". I encountered a bunch of problems trying to get the old example working against the "Sumo" release 2.5.
If you're like me, the first error you encountered following the book's instructions was that you copied across bitbake.conf and got:
ERROR: ParseError at /tmp/bbhello/conf/bitbake.conf:749: Could not include required file conf/abi_version.conf
And after copying over abi_version.conf as well, you kept finding more and more cross-connected files that needed to be moved, and then some relative-path errors after that... Is there a better way?
Here's a series of steps which can allow you to bitbake nano based on the book's instructions.
Unless otherwise specified, these samples and instructions are all based on the online copy of the book's code-samples. While convenient for copy-pasting, the online resource is not totally consistent with the printed copy, and contains at least one extra bug.
Initial workspace setup
This guide assumes that you're working with Yocto release 2.5 ("sumo"), installed into /tmp/poky, and that the build environment will go into /tmp/bbhello. If you don't the Poky tools+libraries already, the easiest way is to clone it with:
$ git clone -b sumo git://git.yoctoproject.org/poky.git /tmp/poky
Then you can initialize the workspace with:
$ source /tmp/poky/oe-init-build-env /tmp/bbhello/
If you start a new terminal window, you'll need to repeat the previous command which will get get your shell environment set up again, but it should not replace any of the files created inside the workspace from the first time.
Wiring up the defaults
The oe-init-build-env script should have just created these files for you:
bbhello/conf/local.conf
bbhello/conf/templateconf.cfg
bbhello/conf/bblayers.conf
Keep these, they supersede some of the book-instructions, meaning that you should not create or have the files:
bbhello/classes/base.bbclass
bbhello/conf/bitbake.conf
Similarly, do not overwrite bbhello/conf/bblayers.conf with the book's sample. Instead, edit it to add a single line pointing to your own meta-hello folder, ex:
BBLAYERS ?= " \
${TOPDIR}/meta-hello \
/tmp/poky/meta \
/tmp/poky/meta-poky \
/tmp/poky/meta-yocto-bsp \
"
Creating the layer and recipe
Go ahead and create the following files from the book-samples:
meta-hello/conf/layer.conf
meta-hello/recipes-editor/nano/nano.bb
We'll edit these files gradually as we hit errors.
Can't find recipe error
The error:
ERROR: BBFILE_PATTERN_hello not defined
It is caused by the book-website's bbhello/meta-hello/conf/layer.conf being internally inconsistent. It uses the collection-name "hello" but on the next two lines uses _test suffixes. Just change them to _hello to match:
# Set layer search pattern and priority
BBFILE_COLLECTIONS += "hello"
BBFILE_PATTERN_hello := "^${LAYERDIR}/"
BBFILE_PRIORITY_hello = "5"
Interestingly, this error is not present in the printed copy of the book.
No license error
The error:
ERROR: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb: This recipe does not have the LICENSE field set (nano)
ERROR: Failed to parse recipe: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
Can be fixed by adding a license setting with one of the values that bitbake recognizes. In this case, add a line onto nano.bb of:
LICENSE="GPLv3"
Recipe parse error
ERROR: ExpansionError during parsing /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
[...]
bb.data_smart.ExpansionError: Failure expanding variable PV_MAJOR, expression was ${#bb.data.getVar('PV',d,1).split('.')[0]} which triggered exception AttributeError: module 'bb.data' has no attribute 'getVar'
This is fixed by updating the special python commands being used in the recipe, because #bb.data was deprecated and is now removed. Instead, replace it with #d, ex:
PV_MAJOR = "${#d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${#d.getVar('PV',d,1).split('.')[1]}"
License checksum failure
ERROR: nano-2.2.6-r0 do_populate_lic: QA Issue: nano: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]
This can be fixed by adding a directive to the recipe telling it what license-info-containing file to grab, and what checksum we expect it to have.
We can follow the way the recipe generates the SRC_URI, and modify it slightly to point at the COPYING file in the same web-directory. Add this line to nano.bb:
LIC_FILES_CHKSUM = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
The MD5 checksum in this case came from manually downloading and inspecting the matching file.
Done!
Now bitbake nano ought to work, and when it is complete you should see it built nano:
/tmp/bbhello $ find ./tmp/deploy/ -name "*nano*.rpm*"
./tmp/deploy/rpm/i586/nano-dbg-2.2.6-r0.i586.rpm
./tmp/deploy/rpm/i586/nano-dev-2.2.6-r0.i586.rpm
I have recently worked on that hands-on hello world project. As far as I am concerned, I think that the source code in the book contains some bugs. Below there is a list of suggested fixes:
Inheriting native class
In fact, when you build with bitbake that you got from poky, it builds only for the target, unless you mention in your recipe that you are building for the host machine (native). You can do the latter by adding this line at the end of your recipe:
inherit native
Adding license information
It is worth mentioning that the variable LICENSE is important to be set in any recipe, otherwise bitbake rises an error. In our case, we try to build the version 2.2.6 of the nano editor, its current license is GPLv3, hence it should be mentioned as follow:
LICENSE = "GPLv3"
Using os.system calls
As the book states, you cannot dereference metadata directly from a python function. Which means it is mandatory to access metadata through the d dictionary. Bellow, there is a suggestion for the do_unpack python function, you can use its concept to code the next tasks (do_configure, do_compile):
python do_unpack() {
workdir = d.getVar("WORKDIR", True)
dl_dir = d.getVar("DL_DIR", True)
p = d.getVar("P", True)
tarball_name = os.path.join(dl_dir, p+".tar.gz")
bb.plain("Unpacking tarball")
os.system("tar -x -C " + workdir + " -f " + tarball_name)
bb.plain("tarball unpacked successfully")
}
Launching the nano editor
After successfully building your nano editor package, you can find your nano executable in the following directory in case you are using Ubuntu (arch x86_64):
./tmp/work/x86_64-linux/nano/2.2.6-r0/src/nano
Should you have any comments or questions, Don't hesitate !
Using Poky (v. 13.0 - Yocto 1.8), I am trying to build the core-image-minimal but excluding the opkg package.
In the generated rootfs, I still have a /usr/lib/opkg/ populated folder.
I tried to play with the following in my build/conf/local.conf
DISTRO_FEATURES_remove += " package-management"
IMAGE_FEATURES_remove += " package-management"
EXTRA_IMAGE_FEATURES_remove += " package-management opkg"
IMAGE_INSTALL_remove += " package-management opkg"
POKY_DEFAULT_EXTRA_RRECOMMENDS = ""
I saw that in meta-yocto/conf/distro/poky-tiny.conf there is the following, which I tried to add (still in my local.conf without success)
PACKAGECONFIG_pn-opkg-utils = ""
Well, if you ensure that IMAGE_FEATURES doesn't contain package-management, that should be enough. (Unless you manually install eg opkg).
Have you looked at /usr/lib/opkg? In my image, that directory only contains alternatives, which in turns holds information about alternative versions of installed applications. See eg update-alternatives.
Do you have any other files or directories under /usr/lib/opkg?
============== Update ==============
These files are not really needed, unless you want/need to run update-alternatives. This could also be run if you do package based updates. However, on a read-only rootfs, these shouldn't be needed.
Something like this could be used if you want /usr/lib/opkg to be removed:
remove_alternative_files () {
rm -rf ${IMAGE_ROOTFS}/usr/lib/opkg
}
ROOTFS_POSTPROCESS_COMMAND += "remove_alternative_files;"
This can be added either directly in your recipe, or if you have a custom image-class.
I'm trying to get vim set up as an IDE for Perl. I'm using generic, text-based vim, not gvim.
I installed the "vim-perl" addon at https://github.com/vim-perl/vim-perl using the vim addon manager per the suggestion of someone else. At least I think it's installed but I don't notice any difference in how the file is processed.
First I installed the vim-addon-manager with Debian's package manager. Then I put the following code in my .vimrc file and reloaded it:
" put this line first in ~/.vimrc
set nocompatible | filetype indent plugin on | syn on
fun! SetupVAM()
let c = get(g:, 'vim_addon_manager', {})
let g:vim_addon_manager = c
let c.plugin_root_dir = expand('$HOME', 1) . '/.vim/vim-addons'
" Force your ~/.vim/after directory to be last in &rtp always:
" let g:vim_addon_manager.rtp_list_hook = 'vam#ForceUsersAfterDirectoriesToBeLast'
" most used options you may want to use:
" let c.log_to_buf = 1
" let c.auto_install = 0
let &rtp.=(empty(&rtp)?'':',').c.plugin_root_dir.'/vim-addon-manager'
if !isdirectory(c.plugin_root_dir.'/vim-addon-manager/autoload')
execute '!git clone --depth=1 git://github.com/MarcWeber/vim-addon-manager '
\ shellescape(c.plugin_root_dir.'/vim-addon-manager', 1)
endif
" This provides the VAMActivate command, you could be passing plugin names, too
call vam#ActivateAddons([], {})
endfun
all SetupVAM()
" ACTIVATING PLUGINS
" OPTION 1, use VAMActivate
VAMActivate github:vim-perl/vim-perl
" OPTION 2: use call vam#ActivateAddons
"call vam#ActivateAddons([vim-perl], {})
use <c-x><c-p> to complete plugin names
" OPTION 3: Create a file ~/.vim-srcipts putting a PLUGIN_NAME into each line
" See lazy loading plugins section in README.md for details
" call vam#Scripts('~/.vim-scripts', {'tag_regex': '.*'})
So what exactly is the vim-perl addon supposed to do for me? I can't find any good documenation anywhere.
At least parts of vim-perl are incorporated in the factory-default configuration of Vim; cp. $VIMRUNTIME/ftplugin/perl.vim and $VIMRUNTIME/syntax/perl.vim. By installing (and regularly upgrading) the plugin, you'll get:
a newer version of the scripts, with potential enhancements and bug fixes
some additional functionality (f.e. there's a syntax/mason.vim that's not yet in Vim itself)
If you regularly edit non-trivial Perl scripts, or use latest language features, installing vim-perl is worth contemplating. If you're just a casual programmer, I would wait until a real need arises.