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 !
I have following code in on of roles:
- name: Create user group
group: name={{ user.group }} state=present
tags:
- user
When I run ansible-playbook -i localhost --ask-become-pass playbook.yml I catch an error:
ERROR! conflicting action statements: group, tags
The error appears to have been in '/home/user/spark/roles/base/tasks/main.yml': line 12, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: Create user group
^ here
...
exception type: <class 'ansible.errors.AnsibleParserError'>
exception: conflicting action statements: group, tags
...
Full error log: https://www.pastiebin.com/59cb4faf9ae35
If I remove tags it runs without error.
It was compnow it is exception: unexpected parameter type in action: after I leave only name and tags. Full error log: pastiebin.com/59cb5b2996a10letely ok all the time but now it works like this without any identifiable reason. I tried to use previous working version of playbook (through git checkout ) but error exists anyway :(
I would be grateful for any hint on this.
P.S. I have fork of ansible playbook for Archlinux machine.
P.P.S.
ansible 2.4.0.0
config file = /home/user/spark/ansible.cfg
configured module search path = [u'/home/user/spark/library/ansible-aur']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.14 (default, Sep 20 2017, 01:25:59) [GCC 7.2.0]
Ansible aur:
[submodule "library/ansible-aur"]
path = library/ansible-aur
url = https://github.com/pigmonkey/ansible-aur.git
ansible.cfg
[defaults]
library = ./library/ansible-aur
UPD. If I remove group keyword like this:
- name: Create user group
tags:
- user
I catch an error: unexpected parameter type in action: after I leave only name and tags. Full error log: pastiebin.com/59cb5b2996a10
That's pretty funny story.
I have vim plugin that creates ctags tags for a project. And it created file named: spark/library/ansible-aur/tags.
It wasn't python file or something. It was just common ctags file.
I found that it was the root of all troubles by using pdb debugger with ansible code.
I've found one of error strings I saw: conflicting action statements in ansible code:
> /usr/lib/python2.7/site-packages/ansible/parsing/mod_args.py(293)parse()
-> raise AnsibleParserError("conflicting action statements: %s, %s" % (action, item), obj=self._task_ds)
And injected pdb.set_trace() there.
Then I make some study:
(Pdb) item
u'tags'
(Pdb) item in module_loader
True
(Pdb) module_loader.find_plugin(item)
u'/home/user/spark/library/ansible-aur/tags'
Last line was kind of hint. After deleting that tags file everything was completely ok.
Corresponding bug report: https://github.com/ansible/ansible/issues/31070
I am trying to configure accesslog. I have changed the slapd.conf file and trying to test using slaptest but i am getting error while executing slaptest -f /etc/openldap/slapd.conf.
slapd.conf configuration:
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
.
.
modulepath /usr/lib/openldap/
moduleload accesslog.la
overlay accesslog
logdb "cn=accesslog"
logops writes
logsuccess TRUE
I am getting error at overlay accesslog
overlay "accesslog" not found
slaptest: bad configuration file!
Am I missing something..?
I found the issue on my own. I have not compiled the openldap with --enable overlay.
To solve this issue
i have downloaded the openldap src
./configure --enable-overlays (./configure [options] [variable=value ...])
Now modify the slapd.conf to load accesslog.la and execute slaptest -f /etc/openldap/slapd.conf. Now you wont find any error.
restart the slapd.
I installed Composer and a SDK for Mailgun's service. These are the steps i followed:
# current directory
cd ~
# Install Composer
curl -sS https://getcomposer.org/installer | php
# Add Mailgun as a dependency
php composer.phar require mailgun/mailgun-php:~1.7
According to the instructions, all I did after that was (index.php):
<?php
require 'vendor/autoload.php';
use Mailgun\Mailgun;
# First, instantiate the SDK with your API credentials and define your domain.
$mg = new Mailgun("key-my-key-goes-here-987654321");
$domain = "somedomain.com";
Then, I tried to get the list of bounced emails:
$data = $mg->get("$domain/bounces", array('limit' => 15, 'skip' => 0));
var_dump($data);
...and I'm getting this error:
Warning: require(vendor/autoload.php): failed to open stream: No such
file or directory in /var/www/html/index.php on line 2 Fatal error:
require(): Failed opening required 'vendor/autoload.php'
(include_path='.:/usr/share/pear:/usr/share/php') in
/var/www/html/index.php on line 2
So I'm guessing it has something to do with composer's installation/configuration perhaps? Thanks for any help...
The way you programmed it, you must have the following files all in the same directory:
composer.json
index.php (your test script)
And you must have run the composer require command while being inside this directory. This will also create a directory named vendor here, and add plenty of files, amongst them vendor/autoload.php.
If however your test script isn't in this location, the require call will not find the file where you tell PHP to find it. This isn't any failure of Composer, but simply the fact that you have to include that file according to your situation, not by copy&paste code. If you change the path of your test script, you have to change the path of the vendor directory as well.
I've been able to get JSDoc3 working with the default template, however, when I try to run another template (even the one that comes with it,haruki) I get the following error:
js: "/path/to/jsdoc/jsdoc.js", line 308: exception from uncaught JavaScript throw: Error: Unable to load template: Module "haruki/publish" not found.
I've tried several other templates and get the same thing. Goven my freshman status with JSDoc I'm assuming it's some config or call issue that's tripping me up.
try to set full path to template folder with publish.js file (not only template name)
for example command line parameter
-t templates/docstrap-master/template
or in config.json file
{ ...
"opts": {
...
"template": "templates/docstrap-master/template"
}
}
it works for this https://github.com/terryweiss/docstrap
for Haruki it seems to work too ./jsdoc -c conf.json -t templates/haruki but i have another error:
This template only supports output to the console. Use the option "-d
console" when you run JSDoc.
With -d console it prints result to console