Remove netdata package from Yocto - yocto

I'm trying to get rid of netdata from my Yocto environment. So I added it to the IMAGE_INSTALL_remove variable inside my <image>.bb file:
IMAGE_INSTALL_remove = "netdata"
I also added it to conf/bblayers.conf file:
DISTRO_FEATURES_remove = "netdata"
Then I removed the output directory (rm -rf tmp-glibc) and the buildhistory/.../netdata directory and I bitbaked my image again.
Unfortunately the package is still compiled and goes into the output folder.

Yocto is hard to learn, and I'm still learning it, so I'm not a Yocto expert, and might even be wrong. But I hope I can help you.
I think that you don't have to modify your bblayers.conf by adding
DISTRO_FEATURES_remove = "netdata"
Are you sure that the netdata package is not needed by any other packages? For example, if inside recipe-a.bb you have:
RDEPENDS += "recipe-b"
Then recipe-b is automatically included in the result image.
My advice is: check the netdata dependencies with
bitbake -g <packagename-or-imagename> -u taskexp
Because maybe this is needed from some other package, and you have to remove the other package too in order to see netdata removed.
If the package is always there, as a last resort you can also try to clean the entire image with:
bitbake -c cleanall <imagename>
And then rebuild it with:
bitbake <imagename>
Source: https://www.openembedded.org/wiki/Inspect_DEPENDS

Related

How to install tar.gz package to Yocto by adding new layer?

I new to Yocto so there are probably some mistakes and misunderstanding that I've had, I appreciate if you can help.
So, I want to add a new package (tar file) to my custom image.
I have followed steps and steps in manual and some online instructions. While running: "bitbake mylayer", the layer is built fine but I got this error while building the image, here is the log file:
DEBUG: Executing python function rootfs_deb_bad_recommendations
DEBUG: Python function rootfs_deb_bad_recommendations finished
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Installed into sysroot: []
NOTE: Skipping as already exists in sysroot: ['depmodwrapper-cross', 'apt-native', 'dpkg-native', 'pseudo-native', 'update-rc.d-native', 'prelink-native', 'makedevs-native', 'ldconfig-native', 'opkg-util$
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing python function do_rootfs
NOTE: ###### Generate rootfs #######
NOTE: Installing the following packages: apt busybox copy-uefiimg-to-sda coreutils dpkg e2fsprogs-resize2fs libfontconfig1 libfreetype6 libglib-2.0-0 gptfdisk libjemalloc2 kernel-module-axi-dma-sensor ku$
ERROR: Unable to install packages.
Reading package lists...
Building dependency tree...
Reading state information...
Package mypackage is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'mylayer' has no installation candidate
DEBUG: Python function do_rootfs finished
ERROR: Function failed: do_rootfs
And here is mylayer.bb:
SUMMARY = ""
LICENSE = "CLOSE"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://mypackage.tar"
Also, I have included the package in conf/local.conf:
IMAGE_INSTALL_append += " mylayer"
So beside trying to figure out how to solve this problem, I also have some questions:
I have read some example of .bb, and they mentioned about LIC_FILES_CHKSUM. The mypackage.tar.gz is a package to install a platform for the device and I don't know much about the source code, so I don't know if it is necessary to include the license? Or how to know that this package need license to install?
In some answer I found online, there is one saying that I need to include PACKAGE_CLASSES ?= "package_deb" (they want to install the .deb file), so probably in my case I will need PACKAGE_CLASSES ?= "package.tar" right? I have tried to change variable, but it still not successful.
The mypackage.tar includes some deb files. If I could not install mypackage.tar, can I instead install these .deb files? Can I put it all in mylayer.bb?
Thank you in advanced, I have tried to study much documents as I could but I get so confused and there is huge amount of information to digest.
First, before answering your questions
Let me mention some best practices advice for you:
Rename the recipe to some significant name related to you compressed package.
Naming the recipe to mylayer confuses Yocto users, because there is the term layer also.
Regarding you recipe:
There is no need for FILESEXTRAPATHS because the recipe path is added automatically to Yocto paths.
FILESEXTRAPATHS it is required for .bbappend files.
You need to override the do_install task function, it does nothing by default.
do_install is the first essential task to make sure that your sources are included in the final image.
Beside that, when specifying a compressed source file into SRC_URI, yocto automatically decompresses it.
This is mentioned here.
So, here what your recipe should look like:
SUMMARY = ""
LICENSE = "CLOSED"
# Prevent Yocto from decompressing the file
SRC_URI = "file://mypackage.tar;unpack=0"
do_install(){
# Create the opt folder into the final image, ${D} is ${WORKDIR}/image
install -d ${D}/opt
# Copy the compressed file there; You can change permissions as you want
install -m 0755 ${WORKDIR}/mypackage.tar ${D}/opt
}
# Very important to specify what you installed in (do_install)
FILES_${PN} = "/opt/*"
Now, when you run IMAGE_INSTALL_append += " mylayer" your file will be installed.
Regarding your questions:
You mentioned that your compressed file contains .deb files, I assume that no license checksum is needed. Also, I understand that you may wanted to point to SRC_URI[md5sum] or other checksums for the full package. That is also not needed for local files, it is used to check for the integrity of online sources.
PACKAGE_CLASSES as mentioned here, is used by the system to know in what type the data should be packaged. By the data I mean the data that you installed with do_install. That data get packaged for according to your PACKAGE_CLASSES variable, for example, to deb file. And that is used, along side with all other recipes packages, to build the final rootfs.
Yes, if you are installing the tar file into the image and then unpack it to install all deb files, for example, with dpkg. You can use the bin_package class to do that, now the recipe must be changed for that reason:
Decompress the tar file and provide the deb files in the local files folder.
Add all deb files to SRC_URI
Inherit the bin_package class
Specify the files to be packaged.
Your recipe should look like this:
SUMMARY = ""
LICENSE = "CLOSED"
SRC_URI = "file://deb_file1.deb \
file://deb_file2.deb"
# No need to `do_install` , it is invoked by the (bin_package) class
FILES_${PN} = ""
Important:
About FILES_${PN}, you need to add all what the deb installed into the image folder
Example, if your deb file installs this:
/usr/bin/hello
/etc/hello.cfg
Specify them:
FILES_${PN} = "/usr/bin/*"
FILES_${PN} += "/etc/*"
Use * so if other deb files install files into the same folder as others it will include all.

Problem with Yocto recipe modification (.bbappend)

I am new in Yocto environment, and I am trying to modify my initscripts recipe (from Poky) with .bbappend file. The problem is that everything I tried with it, it never worked. My file (../sources/recipes-core/initscripts/initscripts_%.bbappend) contains:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://type.sh"
do_install_append () {
install -d ${D}/${sysconfdir}/init.d/test
install -m 755 ${WORKDIR}/type.sh ${D}${sysconfdir}/init.d/test/type.sh
update-rc.d -r ${D} type.sh start 30 2 3 4 5 .
}
It seems that nothing is working ("test" folder is not even created in the rootfs, nor with another folder in /etc).
If I write a mistaken file in SRC_URI in .bbbappend file, bitbake shows a warning (OK).
If I write some syntax error in .bbappend file, bitbake not finishes, it returns an error (OK).
Typing bitbake-layers show-appends , I can see that my .bbappend file appears and it is not skipped.
Maybe the problem is the bitbake, I am doing it with bitbake core-image-minimal, maybe I need another target.
Please, let me know any advice because I don't know what else I can check.
Thank you so much,

Yocto: : does bitbake cleanall ,cleans dependencies as well

bitbake cleanall
Removes all output files, shared state cache, and downloaded source files for a target
It is not clear or documented if it cleans all build time dependencies as well
If you want to clean everything do,
bitbake world -c cleanall --continue
The --continue will ignore any dependency errors while cleaning. Continue as much as possible after an error.
No, cleanall does not clean dependencies. eg
bitbake -c cleanall core-image-minimal
only removes the output of that named recipe.
What i usually do to clean "everything" is running cleanall on the receipe "world":
bitbake -c cleanall world
If that fails because of unresolvable packages like that:
ERROR: Nothing PROVIDES 'sg3-utils' (but /home/blubb/meta-freescale/recipes-devtools/utp-com/utp-com_git.bb DEPENDS on or otherwise requires it).
I just add the packages temporary to the ASSUME_PROVIDED variable like this :
bitbake -c cleanall world --ignore-deps=python-nativedtc-native --ignore-deps=sg3-utils
If nothing provides this packages it is unlikely that they where ever build.
Please read the mega-manual section do_cleanall .
do_cleanall removes:
all output files
shared state (sstate) cache
and downloaded source files for a target (i.e. the contents of DL_DIR).
You can run this task using BitBake as follows:
$ bitbake -c cleanall <recipe-name>
If recipe name is not passed to cleanall task it does not work.
Removes all output files, shared state (sstate) cache, and downloaded source files for a target (i.e. the contents of DL_DIR). Essentially, the do_cleanall task is identical to the do_cleansstate task with the added removal of downloaded source files.
You can run this task using BitBake as follows:
$ bitbake -c cleanall recipe
Typically, you would not normally use the cleanall task. Do so only if you want to start fresh with the do_fetch task.
Other folks have already answered that bitbake does not automatically clean dependencies, but you can create an Inter-task dependency (https://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#inter-task-dependencies) to clean your dependencies if needed by adding a command to the recipe:
do_task[depends] = "recipe:task"
We've extended bitbake to build native recipes and automatically run unit tests during a build. In that case we need to clean the native recipe when cleaning the target so you could add:
do_clean[depends] = "${PN}-native:do_clean"
do_cleanall[depends] = "${PN}-native:do_cleanall"
do_cleansstate[depends] = "${PN}-native:do_cleansstate"
That solution falls a bit short because the native recipes will attempt to clean ${PN}-native-native, so you'll need a conditional to not apply if it's already native:
do_clean[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_clean'}"
do_cleanall[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_cleanall'}"
do_cleansstate[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_cleansstate'}"

How to include irdadump into Yocto (Poky) irda-utils 0.9.18 package

Please excuse my lack of knowledge and incorrect use of terminology. I
am looking to include irdadump in my build image within Yocto.
I modified the
/poky/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb file to
include irdadump in the list of targets to be built.
INITSCRIPT_NAME = "irattach"
INITSCRIPT_PARAMS = "defaults 20"
TARGETS ??= "irattach irdaping irdadump"
do_compile () {
for t in ${TARGETS}; do
oe_runmake -C $t
done
}
However the bitbake process fails which comes down to the dependency of
pkg-config and glib 2.0 required for idradump.
I did a quick search online and noticed that there was a separate .bb
file for irdadump:
http://cgit.openembedded.org/openembedded/plain/recipes/irda-utils/
I tried to replicate this however was still faced with compiling issues.
Could anyone give me a helping hand on including irdadump to my
irda-utils package?
Thank you
To add irda-utils to your build image, just add IMAGE_INSTALL_append in your conf/local.conf file.Next time when you will run Bitbake,it will include irda-utlis package in your build image.
IMAGE_INSTALL_append = " irda-utils"

Compile rygel for yocto with plugins

I'm using bitbake to compile rygel for yocto from the meta-openembedded layer, with the plugins mpris and gst-launch.
As per the PACKAGECONFIG docs, I created a bbappend file and added the following:
EXTRA_OECONF = "--disable-introspection \
--disable-tracker-plugin \
--with-media-engine=gstreamer \
--enable-mpris-plugin \
--enable-gst-launch-plugin"
PR = "r1"
It compiles and installs, but has no plugins.
The append shows up when I run bitbake-layers show-appends, so at least bitbake is finding it. After running bitbake the directory tmp/work/core2-64-poky-linux/rygel/0.26.1-r1/image/usr/lib/rygel-2.6/plugins/ is populated. Then when I run the image /usr/lib/rygel-2.6/ contains an engines dir and nothing else.
Any idea where I'm going wrong?
I don't think your read all the way down to "If you want to change an existing PACKAGECONFIG block, you can do so one of two ways:".
From a bbappend, just do
PACKAGECONFIG_append = " mpris gst-launch"
In the recipe do_install, they remove some of the engines and plugins files. This might be the reason you do not see them in your image.
do_install_append() {
# Remove .la files for loadable modules
rm -f ${D}/${libdir}/rygel-${LIBV}/engines/*.la
rm -f ${D}/${libdir}/rygel-${LIBV}/plugins/*.la
}
your compiling plugins successfully and not able to see in board(rootfs)? if yes please add below line in your .bbappend file. '
FILES_${PN} += "${libdir}/*"
this will add all your compiled plugins to your rootfs image.