I need ldd utility in my final image of yocto. When I needed usbutils before, I went ahead and added the line in ../build/conf/local.conf file
CORE_IMAGE_EXTRA_INSTALL += "usbutils"
After searching around I came to see that ldd is part of the libc-bin package, atleast on my Ubuntu machine. But after reading this, I see that it is in eglibs recipe and not part of the standard package. Adding libc-bin similar to usbutils threw a Nothing RPROVIDES libc-bin error which is understandable.
What are the steps I take to get ldd onto my image if I need to add eglibs recipe. If not, is there another way I can do this.
Please bear with me, still a newbie with yocto and bitbake.
How to add "ldd" to your image depends on the used C library.
In case of glibc:
At least for the current "zeus" version the glibc recipes provide a separate ldd package, see: https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc-package.inc?h=zeus#n27
In case of musl:
At least for the current "zeus" version the musl package itself provides ldd, see: https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/musl/musl_git.bb?h=zeus#n91
Adding packages to your image can be done in various ways but I would recommend to use
IMAGE_INSTALL_append. For more info in this topic please consult the YoctoProject manual: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#usingpoky-extend-customimage.
Related
I'm in the process of upgrading from Yocto Sumo to Yocto Dunfell. In this process there's quite a few packages getting added to the rootfs that wasn't there before and which I don't have use for. I would like to know why they are added? Which dependency triggers them to get added?
In previous versions of Yocto there was a pn-depends.dot file which provided this information. This has now been removed. All that is left is a task-depends.dot which I guess I should use, however it is harder to read as it lists dependencies between individual tasks and doesn't show why a certain package is added to the rootfs. The command bitbake -g <image-name> -u taskexp makes it slightly easier to read the file but it is still hard to understand as package names are not always the same as task names.
What is the preferred solution to get an answer to "why is included in my rootfs?"
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 have a package I just updated to use setuptools_scm and found the version number is wrong in readthedocs.
http://sshuttle.readthedocs.org/en/v0.77/ shows:
Version: 0.78.dev0+ng083293e.d20160304
however as version 083293e has the 0.77 tag, the version string should be just 0.77
It looks like readthedocs might be making changes to my source code before building.
I have looked at the readthedocs build logs, and it seems to have the correct version at one stage (0.77), however this is before it builds the documentation.
Processing dependencies for sshuttle==0.77
Finished processing dependencies for sshuttle==0.77
The build logs don't mention the version while building the documentation.
Is it possible to solve this?
Thanks
I see that you're building this project.
Clearly, something is mutating the repository state before the version is determined. You can replicate similar behavior by mutating one of the files prior to building the docs yourself:
(sshuttle) $ python setup.py --version
0.77
(sshuttle) $ cat >> setup.py
# a comment
(sshuttle) $ python setup.py --version
0.78.dev0+ng083293e.d20160403
In the read the docs docs, there's a description of the process.
There, you can see the steps RTD does, namely, (a) run setup.py install then (b) install requirements in requirements.txt.
I've confirmed that neither of those steps should be mutating the repo state.
What it doesn't explain, however, is where that 'version' comes from, or what update_imported_docs does. I suspect the issue lies in something subtle that read the docs is doing that modifies the repo.
Here's one place where the conf.py file gets modified.
Perhaps adding docs/conf.py to your .gitignore will allow those changes to be ignored and thus not dirty your working state when calculating the project version.
https://github.com/pypa/setuptools_scm/issues/84 has been updated to record this
we will be working with the sphinx team to provide a automated/painless version of this process
The documentation for setuptools_scm now has instructions on how to use with readthedocs:
It is discouraged to use setuptools_scm from sphinx itself, instead
use pkg_resources after editable/real installation:
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])
The underlying reason is, that
services like readthedocs sometimes change the workingdirectory for
good reasons and using the installed metadata prevents using needless
volatile data there.
This avoids the need to use kluges as per the other answer.
I followed the instructions in GStreamer Plugin Writer's Guide (1.7.1.1):
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
in order to build a new gstreamer plugin. Basically I ran make_element and then edited Makefile.am as described. Amazingly make and make install worked and I ended up with:
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.la
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.so
As I understand it, gst-inspect should find this plugin automatically. The guide says that /usr/local/lib/gstreamer-1.0 needs to be added to GST_PLUGIN_PATH in order for plugins in this directory to be found. Another document states that this directory is searched automatically. I tried with and without the environment variable, but no luck.
Now I should say that I have just started to use gstreamer and I am suffering from total information overload. I have read so many documents, yet I don't even know whether I am building a gstreamer1.0 or a gstreamer0.10 plugin (I think the guide is for gstreamer1.0, since the guide's version is 1.7.1.1 but can't be sure).
Can anybody give me a clue here ?
There are many possible reasons that can cause this issue.
First, check if your plugin is blacklisted by command gst-inspect-1.0 -b.
If your plugin show up here, that means it is really blacklisted.
In that case, delete directory ~/.cache/ and then run gst-inpect-1.0 again.
This will force GStreamer to re-scan plugins list. If the reason of blacklist is not solved yet, gst-inpect will probably print out the reason here for you.
Another possible reason (but unlikely happens) is setting GST_REGISTRY_UPDATE as no, which will force GStreamer NOT to rescan the plugin directory, thus not found new plugin
P/s: The guide is for GStreamer 1.0
If you've tried removing your plugin from the blacklist and it still doesn't show up, try this:
export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0
/usr/local/lib/gstreamer-1.0 is the default directory used by make in case of plugins. If you have defined a different directory, use it.
Then run gst-inspect-1.0 and you'll find the newly compiled and installed plugin.
You'll be required to perform the export every time in the shell whether you either create a static pipeline with gst-launch-1.0 or run code of your own. I couldn't find any alternative to make it permanent other than making entry of this in .bashrc file. If you have one, please suggest via comments.
If you run ./configure --help in the gst-plugin directory you will see the following:
By default, make install' will install all the files in
/usr/local/bin', /usr/local/lib' etc. You can specify
an installation prefix other than/usr/local' using --prefix',
for instance--prefix=$HOME'.
If you do after the original installation:sudo updatedb && locate libgst[NAME_OF_YOUR_PLUGIN].so you should see where the library holding your plugin is located (in my case it is under /usr/local/lib/gstreamer-1.0/ as described by the configure help above).
Now on my machine, the GStreamer "official" plugins are installed under: /usr/lib/i386-linux-gnu/gstreamer-1.0/ . This is where the new created plugin library should be stored.
To store the plugin at the right place, run configure with the following parameter:
./configure --libdir=/usr/lib/i386-linux-gnu followed by make && sudo make install
It is important to override with --libdir and NOT --prefix! The usage of --prefix will stick a /lib that we don't want to have under /usr/lib/i386-linux-gnu.The plugin will not be found by gst-inspect-1.0 if /lib is added to the path.
Extra note :
Even if the plugin is at the proper location, you may still see GStreamer blacklisting it when you run gst-inspect-1.0. One of the cause of the blacklisting could be the shared library/ies required by your plugin not installed or not found on your platform. The ldd command can help figuring out the dependencies your plugin may have. Just run ldd [YOUR_GSTREAMER_LIBRARY].so
I'm new to python and it was recommended that I use Canopy. I'm trying to follow along with this tutorial, but I get stuck at the mahotas.imread line. I get an error saying that ends with this:
Full error was: mahotas.freeimage: could not find libFreeImage in any
of the following directories:
'/Users/RJD/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/mahotas',
'/lib', '/usr/lib', '/usr/local/lib', '/opt/local/lib'
I've added the mahotas package via the package manager to no avail. Also tried the steps here, with no different result.
I am actually able to find 'freeimage.py' and 'freeimage.pyc' in '/Users/RJD/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/mahotas'. How do I go about telling Canopy that it is there?!
Any help would be very much appreciated.
Cheers,
R
Author of mahotas here:
Mahotas itself does not have the functionality to read in images. imread is just a wrapper around one of 3 backends:
mahotas-imread (i.e., https://pypi.python.org/pypi/imread)
FreeImage (this was the original version and if you have such an old version [0.7.1 is from Jan '12], it might still only support FreeImage)
matplotlib (which only supports PNG & JPEG)
Thus, you need to install one of the packages above.
To be clear, there is no "enthought mahotas". Mahotas is not in the Enthought package repository but in our "Community" (PyPi mirror) repo of 11,000 untested ("as is") packages, as you can see by the "PyPI" logo in the Package Manager (sorry, that's not at all obvious, we'll fix this!) We will be updating this repo later this year. The version of mahotas in that PyPI repo is 0.7.1, whereas the current version of mahotas on PyPI is 1.0.2. So that avenue is not useful for now.
When you say that you tried the steps in the cmu.edu document, was that after uninstalling the old PyPI version just mentioned and going through each step mentioned in that document?