How to add HAProxy package into bitbake recipe - haproxy

I am new to bitbake recipe. I am trying to add HAProxy package into bitbake. I am trying to create a recipe but not sure how to proceed with it.
so far I have just made it till here:
SUMMARY = "HAProxy support for NEXT"
HOMEPAGE = "http://www.haproxy.org/"
SECTION = "tools"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=2d862e836f92129cdc0ecccc54eed5e0"
SRC_URI = "http://www.haproxy.org/download/1.6/src/haproxy-${PV}.tar.gz"
SRC_URI[md5sum] = "3362d1e268c78155c2474cb73e7f03f9"
SRC_URI[sha256sum] = "fd06b45054cde2c69cb3322dfdd8a4bcfc46eb9d0c4b36d20d3ea19d84e338a7"
Can anyone point me to right direction?

haproxy is a Makefile based project, so this link should help:
http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#new-recipe-makefile-based-package
You should define this variable in your recipe:
EXTRA_OEMAKE = "TARGET=XXX"
replacing XXX by the target your are interested (generic, linux22, linux24, and so on). That string TARGET=XXX will be passed as argument to the 'make' command, so bitbake will start compilation. Most probably that's all you need.

Related

Yocto: how to configure an out-of-tree kernel module recipe that uses "inherit module"?

I have written a simple inherit module recipe to build a third-party out-of-tree kernel module called u-dma-buf:
SUMMARY = "User space mappable DMA Buffer"
DESCRIPTION = "${SUMMARY}"
LICENSE = "BSD-2-Clause"
LIC_FILES_CHKSUM = "file://LICENSE;md5=bebf0492502927bef0741aa04d1f35f5"
inherit module
SRC_URI = "git://github.com/ikwzm/udmabuf.git"
SRCREV = "9b943d49abc9c92a464e4c71e83d1c479ebbf80e"
S = "${WORKDIR}/git"
RPROVIDES_${PN} += "kernel-module-u-dma-buf"
This works correctly and generates the module file /lib/modules/[version]/extra/u-dma-buf.ko in the image.
However, looking at the docs there is an option that can be enabled: CONFIG_U_DMA_BUF_MGR that is disabled by default. If I can somehow enable this, then I can expect to find /lib/modules/[version]/extra/u-dma-buf-mgr.ko in the image also.
The project has a Kconfig file. Does bitbake have support for integrating Kbuild configuration outside of the kernel tree? If so, how do I hook into this and enable CONFIG_U_DMA_BUF_MGR? And if not, what's my best option, other than patching the Kconfig file to change the default to "y"? (EDIT: this probably won't work, as kernel sources need to be modified to incorporate Kbuild anyway - so probably a dead end unless it's a specific feature of bitbake I haven't encountered yet).
I see that the upstream Makefile also has the option CONFIG_U_DMA_BUF_MGR=m that could be used to enable this feature outside of Kbuild. I'm not sure how to pass that to the make command line though - would I need to write a custom do_compile task? Looking at the module.bbclass code, I can't see any provision for passing such an option to oe_runmake. Should I just copy/paste module_do_compile() from module.bbclass and add CONFIG_U_DMA_BUF_MGR=m? Is that the best way to do this?
So my question is, given I'm using inherit module, what is the proper way to enable this configuration option, given the recipe I have?
According to the Yocto kernel development docs:
If your module Makefile uses a different variable, you might want to override the do_compile step
That suggests to me that the correct and intended course of action in this case is to copy/paste module_do_compile() as a do_compile() override, and modify accordingly (add CONFIG_U_DMA_BUF_MGR=m):
do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \
KERNEL_VERSION=${KERNEL_VERSION} \
CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
AR="${KERNEL_AR}" \
O=${STAGING_KERNEL_BUILDDIR} \
KBUILD_EXTRA_SYMBOLS="${KBUILD_EXTRA_SYMBOLS}" \
CONFIG_U_DMA_BUF_MGR=m \
${MAKE_TARGETS}
}
Additionally, add the new module to RPROVIDES_${PN}:
RPROVIDES_${PN} += "kernel-module-u-dma-buf kernel-module-u-dma-buf-mgr"

systemd yocto recipe for an existing executable

I'm looking for a template recipe for enabling a systemd recipe in yocto. The executable is already installed by a recipe provided by yocto. The goal of this recipe is to provide make /usr/bin/btattach be run at startup.
As a start I created the following structure in my layer in the appropriate recipe directory:
btattach-systemd/
|-- files
| `-- btattach.service
`-- btattach-systemd.bb
The content of the recipe
SUMMARY = "Writes patterns to the fb device"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
inherit systemd
REQUIRED_DISTRO_FEATURES= "systemd"
SRC_URI = "file://btattach.service"
S = "${WORKDIR}"
do_install () {
install -m 0644 ${WORKDIR}/btattach.service.service ${D}${sysconfdir}/systemd/system
}
SYSTEMD_SERVICE_${PN} = "btattach.service"
Besides that, the IMAGE_INSTALL in the image recipe has been correctly extended with btattach-systemd.
bitbake btattach-systemd runns ok but when trying to build the complete image the at do_rootfs step for the whole image. with the error:
* opkg_solver_install: Cannot install package btattach-systemd.
Ideas on where the bug is?
I think the recipe should look like this (leaving out summary, license, license checksum, and assuming that the binary package is called "btattach"):
SRC_URI = "file://btattach.service"
SYSTEMD_SERVICE_${PN} = "btattach.service"
inherit systemd
do_install_append() {
install -d ${D}${systemd_unitdir}/system
for service in ${SYSTEMD_SERVICE_${PN}}; do
install -m 0644 ${WORKDIR}/${service} ${D}${systemd_unitdir}/system/
sed -i -e 's,#BINDIR#,${bindir},g' ${D}${systemd_unitdir}/system/${service}
done
}
RDEPENDS_${PN} = "btattach"
I am sorry for not commenting your question as I have no reputation for that. Also, LetoThe2nd answer is more complete than mine, but here follows a possible quick fix:
It seems to me you are installing 'btattach.service.service' instead of 'btattach.service'.
Assuming that the .service file is correct, my take on the Yocto recipe and why it might be failing is because that the btattach.service file isn't included with the installation which is what the final line does below.
Have you ensured that you do a bitbake btattach.systemd -c cleanall and bitbake btattach.systemd -c cleanstate beforehand as well, as I noticed you had a typo in the Yocto recipe as btattach.service.service.
SUMMARY = "Writes patterns to the fb device"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
inherit systemd
REQUIRED_DISTRO_FEATURES= "systemd"
SRC_URI = "file://btattach.service"
S = "${WORKDIR}"
do_install () {
install -m 0644 ${WORKDIR}/btattach.service ${D}${sysconfdir}/systemd/system
}
SYSTEMD_SERVICE_${PN} = "btattach.service"
FILES_${PN} += "/lib/systemd/system/btattach.service"

SRC_URI not working in bitabake recipe

I created a bitbake recipe for installing https://pypi.python.org/pypi/Adafruit-GPIO/1.0.3 python package. Following is my recipe
DESCRIPTION = "Library to provide a cross-platform GPIO interface on the Raspberry Pi and Beaglebone Black using the RPi.GPIO and Adafruit_BBIO libraries"
SECTION = "devel/python"
LICENSE = "CLOSED"
PR = "r1"
SRC_URI = "https://pypi.python.org/packages/db/1c/2dc8a674514219f287fa344e44cadfd77b3e2878d6ff602a8c2149b50dd8/Adafruit_GPIO-1.0.3.tar.gz"
inherit pypi setuptools
do_install_append() {
rm -f ${D}${libdir}/python*/site-packages/site.py*
}
do_compile_prepend() {
${STAGING_BINDIR_NATIVE}/python setup.py install ${DISTUTILS_BUILD_ARGS} || \
true
}
SRC_URI[md5sum] = "dfcdb1ba90188d18ba80b6d2958c8c33"
But whenever I try to bitbake recipe I always receive following error
ERROR: Function failed: Fetcher failure for URL: 'https://pypi.python.org/packages/source/A/Adafruit-GPIO/Adafruit-GPIO-1.0.3.tar.gz'. Unable to fetch URL from any source
My question why does bitbake tries to download from some other link while I have some other link in SRC_URI? How can I correct my recipe>
It's pypi.bbclass that specifies another download URL.
So either
remove inherit pypi
or
remove your SRC_URI. In this case, you will also need to set PYPI_PACKAGE = "Adafruit-GPIO" to the correct package name in pypi (as your recipe has a - instead of a _ in its name).
See pypi.bbclass
An untested version of your recipe that at least builds on my system is adafruit-gpio_1.0.3.bb (note, only lowercase letters in the recipe name):
DERIPTION = "Library to provide a cross-platform GPIO interface on the Raspberry Pi and Beaglebone Black using the RPi.GPIO and Adafruit_BBIO libraries"
SECTION = "devel/python"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://PKG-INFO;md5=e41c52dbe1b96447d1c50129a124f586"
SRC_URI[md5sum] = "dfcdb1ba90188d18ba80b6d2958c8c33"
SRC_URI[sha256sum] = "d6465b92c866c51ca8f3bc1e8f2ec36f5ccdb46d0fd54101c1109756d4a2dcd0"
PYPI_PACKAGE = "Adafruit_GPIO"
inherit pypi setuptools

bitbake error package not found in base feeds

I want to include https://pypi.python.org/pypi/ndeflib in my image. Thus I created a recipe for this. Following are the contents of python-ndeflib_0.2.0.bb
DESCRIPTION = "NFC Data Exchange Format decoder and encoder."
SECTION = "devel/python"
LICENSE = "CLOSED"
SRC_URI = "https://pypi.python.org/packages/0c/0f/b9d94cee7847697469c49a25b4d23236de534451990b83008e6bf4fab15b/ndeflib-0.2.0.tar.gz"
do_install_append() {
rm -f ${D}${libdir}/python*/site-packages/site.py*
}
do_compile_prepend() {
${STAGING_BINDIR_NATIVE}/python setup.py install ${DISTUTILS_BUILD_ARGS} || \
true
}
SRC_URI[md5sum] = "b7ae0c34f49289c44c292e24843cfeb1"
I am able to bitbake python-ndeflib successfully
but whenever I try to build my final os image bitbake fsl-image-machine-test
the process fails at the with following error
ERROR: python-ndeflib not found in the base feeds
Thus where I am making mistake?
I had this error (projectname not found in base feeds in do_rootfs)solved in different project (non cmake , non make) with this:
ALLOW_EMPTY_${PN} = "1"
in its *.bb file.
Some other people has this error because they were using capital letters in project name.
Did you try to write a recipe similar to the one in your previousquestion? That should have solved your issue.
Writing something similar to that recipe, gives you python3-ndeflib_0.2.0.bb:
DESCRIPTION = "NFC Data Exchange Format decoder and encoder."
SECTION = "devel/python"
LICENSE = "ISC"
LIC_FILES_CHKSUM = "file://LICENSE;md5=f7c92777f3af9604e192a0d195b6a6a4"
SRC_URI[md5sum] = "b7ae0c34f49289c44c292e24843cfeb1"
SRC_URI[sha256sum] = "baa86a48cf310cf77524f6fa04f5bd90775c4c290116b6b543aa3d6d65b721bf"
inherit pypi setuptools3
Which seems to work pretty well. Note that I used Python 3 instead of two (setuptools3).
Ie inherit setuptools or setuptools3 instead of writing your own do_compile, do_install, etc, unless you really have to.

Yocto version control

We are struggling for version control of our application ,RFS, Uboot and kernel
We have a hello world program. Every time we are changing (patching) new functionality to the program, we have to keep a track on changes with help of version no. We need the version no of this (hello world package) should be auto incremented.
Same we have to do with Linux and uboot.
Does yocto can do this for us? Or do we have any other option to achieve this.
Please suggest us as we are new for all the capabilities of yocto.
A full example of how you can do this:
The important part is SRCREV = "${AUTOREV}" and PV = "${BPV}+gitr${SRCPV}"
DESCRIPTION = "Hello World"
SECTION = "examples"
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = "file://README.md;md5=8386d486d9e820c480636608de5c2d98"
SRCREV = "${AUTOREV}"
BPV = "0.1.0"
PV = "${BPV}+gitr${SRCPV}"
S = "${WORKDIR}/git"
SRC_URI = " git://example/hello_world.git;protocol=http \
"
inherit autotools
RDEPENDS_${PN} += " \
hello-world-runtime-dependency \
"
As alreadypointed out you have to use SRCREV = "${AUTOREV}". To have a version number that changes on each update the PV variable needs to be tweaked in your recipe.
LINUX_VERSION ?= "3.14"
PV = "${LINUX_VERSION}+git${SRCPV}"
You can check the OpenEmbedded kernel recipe for reference.
There is no built in feature for this in yocto to my knowledge. However, you can write your own check mechanism and place it in do_fetch_prepend. Then set the SRCREV programmatically with d.setVar('SRCREV', myshasum).
An option for auto-updates is to set SRCREV = "${AUTOREV}" then have a script that sets PV and/or PR in the recipe. When the recipe is changed, it forces a fetch and AUTOREV means it pulls from HEAD.