I have a Yocto system where I'm running some Chef InSpec scans. Chef InSpec offers a command to check if a package is installed, however, that doesn't work with Yocto (I imagine it would if you'd install a package manager, but I don't want to do that). What would be the best way to check if a certain package is installed on the system?
I know that bitbake can show every package that would be in the built image, but I need to check on the target system. Is there a way I can get this information from bitbake from within a recipe that would just route the output into a file on the rootfs? Or is there a better approach without installing a package manager on the target system?
Inside the folder tmp/deploy/images/$MACHINE/${IMAGE}/
You should see a file named with manifest extension. It is often named like this : [image-name]-[image-version].manifest"
In this file you will find all packages that are present in your linux image built with Yocto, so packages that will be deployed in your target.
Related
I'm developing a free guitar VST plugin that I want to distribute through a .deb package.
In the postinst script, I run the xdg-desktop-menu command to create the launcher for the standalone version (which works fine), but DAWs (like reaper and bitwig) will look for vst plugins inside $HOME/.vst and obviously won't find my plugin there.
At first I thought I needed to create a symlink inside $HOME/.vst but now I know debian packages aren't supposed do anything inside the user's folder. So what should I do instead?
I've set successfully my Yocto build to patch one of the standard kernel modules, and I'd like to make it possible to update that (and possibly some others in the future) module only on the target system using kernel modules RPM file. The only problem is that the patched module is marked with the exact same revision as the original one, so the only way to update would be to force reinstall of all kernel modules.
Is there any way to manually change PR or a similar version-related parameter for a specific kernel module, or maybe tweak the Yocto project in some other way, so the RPM file built upon it would recognize that module as the only one in need of update?
I am writing a bitbake recipe to deploy a third party pre-built tool, similar to this wiki page: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
However, I have a Release and Debug pre-build versions of the tool available as *.so files. How do I distinguish inside the recipe which one of both build types I shall deploy?
Thanks and regards,
Martin
You can have two different virtual recipes each with their own .so file. This then warrants a selection in a configuration file (with PREFERRED_PROVIDER_virtual/my-recipe), so either in a machine or distro configuration file. This is probably preferred if you consider having release and debug distros.
A second option is to install the libraries in two different paths, in two different PACKAGES (use FILES_my-package for that) and make them RCONFLICTS_my-package each other to be sure they can't both be in the rootfs. After that, you could write a pkg_postinst_my-package() task specific to each package that actually move the library from the "different" path to the intended one. This will be run both at build time when creating the rootfs and at runtime on first boot, so you need to make sure to exclude one or the other (it's usually done by checking if ${D} exists, which does at build time but not runtime).
c.f.: http://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html#post-installation-scripts
If you can manage to have both libraries installed in your rootfs and select the one you want with the LIBRARY_PATH environment variable, a simple recipe, with two packages with each library in a different location, will be sufficient.
I have a project that could be built with the Yocto build system to generate a full disk image. According to the existing procedure, I can get only a full disk image that should be flashed on SD card.
And this does not suit my needs because I can't flash the image on the board. In my case, I need to build a certain project (that currently has a recipe) to an executable. (This project currently is a part of the full disk that is built with Yocto)
So I am wondering, is it possible to extract this executable (and the libraries that this executable depends on) from Yocto build files, so that I could copy and install it on the board? Which possibilities do I have to do this? Do I have some quick and dirty way to do this?
P.S: I heard something about that Yocto can provide a package for a certain project, that could be installed by the corresponding package manager on the board. On the board installed dpkg package manager.
It's a solution to add tar.gz to your IMAGE_FSTYPE.
After building the image, you can extract the executable you were looking for from the created archive.
Or you add the output format you need for your target and install the full image.
I am using an automatic package creation pipeline in gitlab-ci, to build Conda packages for software we use in my company.
One of the software we use relies on gtkdocize, and checks for it in the
configure script. It is only needed for the build, not for the execution.
So, I am not able to build the package because the conda-builder image does
not contain this program.
I am new to Conda, and gitlab-ci, and I imagine conda-builder is a generic
Docker image for building Conda packages in general. How can I add a package
to "my" conda-builder image ?
Or maybe there is a build dependency I am missing in my recipe ? I cannot
find where gtkdocize can come from.
Any help would be appreciated.
The gtkdocize binary is used to set up an Autotools-based project using gtk-doc for generating the API reference. You will need to install whatever package provides gtkdocize; on Debian/Ubuntu, the package is called gtk-doc-tools, whereas on Fedora it's called gtk-doc.