I'm just starting out with Yocto. I've purchased the book (Mastering Embedded Linux Programming Third Edition) and waiting on its delivery.
In the meantime, I can't figure out how to add docker-ce to my project which is listed on layers.openembedded.org.
It always says:
ERROR: Nothing PROVIDES 'docker-ce'
Thx.
Ian.
The docker-ce recipe is provided by the meta-virtualization layer. You should clone this layer next to your other layers, then check out the proper release branch (e.g. kirkstone if that's the release you are using). Then add the layer path to your bbappend.conf and you should be able to build docker-ce with bitbake docker-ce.
Related
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.
I'm attempting to build an image with the phytec bsp 18.2 from here: https://wiki.phytec.com/productinfo/phycore-i-mx7/bsp-yocto-fsl-imx7/
I require a newer version of systemd (> 234) and so am substituting the systemd recipe for version 234 from rocko, found here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd?h=rocko by putting this in a custom layer. However, during the do_rootfs step, I receive an error that "No package provides libsystemd.so.0(LIBSYSTEMD_219). I've tried a work-around recommended here: Smart can't install...no package provides shared object file and it didn't solve the issue. I've tried echoing libsystemd.so.0, LIBSYSTEMD_219, and libsystemd.so.0(LIBSYSTEMD_219) to both ${rootfs}/etc/rpm/sysinfo/Providename and ${rootfs}/var/lib/rpm/Providename and had no luck. Does anyone have an idea on how to fix this? I'd appreciate any help that could be offered, and please let me know if I can offer any more information.
I don't know about the yocto wrapper, etc, but in standard RPM-land, this error:
Computing transaction...error: Can't install python3-systemd-234-r0.0#cortexa7hf_neon: no package provides libsystemd.so.0(LIBSYSTEMD_219)
means that there is a .so or executable in the RPM named python3-systemd-234-r0.0 that was compiled with a specific version of libsystemd.so.0 that had the flag LIBSYSTEMD_219. That flag is the "ELF Symbol Versioning" and it's seen most with GLIBC_XX when you try to install an RPM that's too new for a target system (e.g. CentOS 7 RPM on CentOS 6).
The systemd on your target machine is too old, so it only defines the versions it is compatible with, e.g. libsystemd.so.0(LIBSYSTEMD_210) or similar.
What you need to do is build your python3-systemd-234-r0.0 on a machine with the same version of systemd as the target (or cross-compile appropriately), or create a systemd RPM that includes the functionality you're attempting.
So you need to figure out how to apply one of these solutions to your build system; sorry I don't know enough about yocto to help there.
I am trying to build GNOME Calendar on my Ubuntu 18.04.2 system, and so I do
$ meson ./gnome-calendar ./myGCbuild
and then have been installing the missing dependencies that it tells me one by one using apt.
But eventually I run into some more "non-trivial" things such as that my glib-2.0 version needs to be >= 2.58.0 but the latest on apt repository is 2.56.3 and so guess I need to make another build of the latest glib or maybe find on PPA; but so I'm wondering:
Is there some way meson or something else can take care of automatically installing the missing dependencies with the right versions, etc?
Meson isn't a dependency solver. So, No, meson doesn't take care that.
However, if you want to build gnome applications, there is The Newcomers Guide. Check out the Build Project page. It tells you about "Flatpak, a technology for installing and distributing applications and an IDE called Builder, which has good integration with GNOME technologies and Flatpak. This is the recommended method for new contributors, and is the easiest way to get started."
Happy Hacking.
You can have it fall back to a subproject and build the library as a private dependency, however that is not what you want in this case and no its not Mesons job to understand package managers.
You can use conan to manage your third party dependency and then have meson call conan for fetching them.
Your conan file:
[requires]
glib/2.58.3#bincrafters/stable
[generators]
pkg_config
And in your meson.build put:
run_command('conan', 'install', '--install-folder', meson.build_root(), meson.source_root, check: true)
glib_dep = dependecy('glib')
Apt can do this for you: apt-get build-dep gnome-calendar.
I would like to change some code in one element X in gstreamer ugly plugin and rebuild and use it.
How I can do it?
I have gstreamer-0.10 and installed gstreamer-ugly plugin.
I would like to download only gstreamer0-10 ugly plugin code and change it and would like to use the new lib file. How I can do it?
unfortunately gstreamer-ugly depends on a lot of stuff in at least libgstreamer and plugins-base (if you're using linux and your distro provides *-dev packages as debian/ubuntu does).
If you're on debian you could use dpkg-buildpackage after checking out the source using apt-source. The big advantage here is that all the build dependencies can be easily installed.
The manual way will probably need you to first build all the other gstreamer packages have a close look on what ./configure tells you
I'm workin on debian and have already built gstreamer+plugins to backport the recent ones to ubuntu (although I'm not sure if I did it in a best-practice way ;) )
/edit: I'll try to cover the basic steps for ubuntu here:
add the source repositories to apt (check the "source code" checkbox in the ubuntu software center's "software sources" tool
sudo apt-get install dpkg-dev devscripts
sudo apt-get build-dep gst-plugins-ugly0.10
apt-get source gst-plugins-ugly0.10
change to the newly created gst-plugins-base* folder
dpkg-buildpackage (and make sure it works)
change the source to your needs
you can rebuild it any time using dpkg-buildpackage (to simply see if it compiles make might be faster though). This creates a .deb file in the parent folder that you can simply install using dpkg -i
If it's a useful change you might want to get in touch with the gstreamer-devs ;)
On a debian system, run apt-get build-dep gstreamer0.10-plugins-ugly to get all the build dependencies for that package. After that you can build the package from git, source tarball or even rebuild the debian package (using dkgp-buildpackage).
I have a touch panel computer running ARM9. I have successfully built a QtEmbedded SDK image under OpenEmbedded toolchain (I am newbie in this area) for ARM9. I'd like to re-build QtEmbedded images again with few examples that it comes (not all) with due to space limitation on NAND. How can I re-compile this. I have commented out examples in examples.pro but it seems it's building images from existing packages. I am using command: bitbake -b qt4-embedded-image
Please help.
Nimesh
You need to re-run the configure step of the bitbake to rebuild the Makefiles from the .pro files. You can do this by removing the configure stamp for this package. Just rm the do_configure stamp for this package and re-run the bitbake command you did above.