I have a yocto image into which I have included the CUPS package (using IMAGE_INSTALL_append).
While running the OS, I couldn't find the cups file in /etc/init.d.
I started cups using cupsd. When I tried accessing the web interface using localhost:631, I got a not found error. The console shows that it is not able to load resources on any of those URLS:
http://localhost:631/cups.css
http://localhost:631/
http://localhost:631/favicon.ico
The html and related files seem to be listed in the cups.inc file. Are there additional configuration changes that need be made before doing the YOCTO build or on the CUPS setup?
Since I am very new to yocto and developing in a linux environment, I am not sure if I am missing something obvious.
This question is quite old and already has an accepted answer. Nevertheless, it may be of use for someone else facing the same problem of missing static html content of the CUPS Web interface.
The CUPS recipe packages the static web content into cups-doc.
Thus, instead of
IMAGE_INSTALL_append = " cups"
it should be
IMAGE_INSTALL_append = " cups cups-doc"
in your conf/local.conf.
Then, also the files under /usr/share/doc/cups were added to the rootfs.
Check
# Replace <target>, <image> and <version> to match your configuration
# e.g.: raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0
$YOUR_POKY_DIRECTORY/build/tmp/work/<target>/<image>/<version>/rootfs/usr/share/doc/cups
that was entirely missing before adding the cups-doc package.
You made good research pointing to the recipe and were actually close to find the solution.
In the recipe, you can read:
# Remove sysinit script and symlinks if sysvinit is not in DISTRO_FEATURES
if ${#bb.utils.contains('DISTRO_FEATURES','sysvinit','false','true',d)}; then
rm -rf ${D}${sysconfdir}/init.d/
rm -rf ${D}${sysconfdir}/rc*
fi
Is sysvinit in your DISTRO_FEATURES?
If you don't know you can do
bitbake cups -e | grep "^DISTRO_FEATURES="
Related
I am trying to build a system (Yocto based project) using bitbake and one of the steps is that it needs to retrieve an archive.zip file with a hex file in it from a Jenkins instance somewhere and install that somewhere within the kernel.
The problem now is that I have get a bitbake error on the do_fetch step of this precise recipe.
File: '/cache/downloads/firmware-17.zip' has sha256 checksum 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 when 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[sha256sum] = "6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9"
As you can see the expected checksum is identical between what bitbake reads and expects so I don't really understand what to do at the moment.
What I have already tried is:
Ensure that bitbake does a full clean build.
Bump the repository where archive.zip originates from so that the hash isn't the problem.
What I haven't tried yet is:
Manually download the firmware and place it in the /downloads folder of bitbake and mark the recipe as 'fetched' but since it is running in docker that is not a viable solution really.
Has anybody come across something like this?
I suspect there is a stray space in the value set in your recipe. The message hints at that with "9c9 was" showing a double space.
I just added a new package to my Yocto build (this one: How do you properly build gpiod applications from Yocto?), and it works fine as long as I am connected to the internet. The problem is that I am now trying to make the tarball needed to support an offline build.
A little bit about the setup: I am running Yocto Zeus. I work in a VM (Ubuntu 18.04) connected to the internet, but our build agents are not on the network, so we host a mirror. I have this mirror mounted on /mnt/download-mirror. I am trying to generate the tarball needed for the mirror on my VM.
This is the Yocto config that I am using:
BB_NO_NETWORK = "0"
INHERIT += "own-mirrors"
SOURCE_MIRROR_URL = "file:///mnt/download-mirror"
UNINATIVE_URL = "${SOURCE_MIRROR_URL}/uninative/2.7/"
BB_GENERATE_MIRROR_TARBALLS = "1"
SSTATE_MIRRORS = "file://.* file:///mnt/sstate-mirror/PATH"
But when I run Bitbake (I using command bitbake --runall fetch) it completes, but I don't get a tarball for the new package I added. I have looked for this tarball in the poky-downloads folder (the folder I would normally rsync to the mirror server), but it doesn't appear to be there.
Am I missing a configuration or something? I have all the configurations noted in https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3f
EDIT - I also tried setting DL_DIR ?= "/home/gen-ccm-root/Downloads" in my conf file, but my command still said there was nothing to do, so I think the issue might be my bitbake command. I have also tried bitbake -c mi-dev --runall="fetch" where mi-dev is my target (per 7.23.2 in https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#setting-up-effective-mirrors) to no avail.
Hopefully someone can edit this and put in more information as to why, but I did manage to get it to generate a tarball.
Cleaned my VM which entailed deleting the sstate-cache and poky-downloads.
Modify the local.conf to have the following at the end (I think the DL_DIR is optional):
BB_NO_NETWORK = "0"
DL_DIR ="/home/gen-ccm-root/Downloads"
BB_GENERATE_MIRROR_TARBALLS = "1"
Run command: source oe-init-build-env build-dev
Run command: bitbake mi-dev --runonly=fetch
Mount the network share containing the download mirror.
Copy the files over:
sudo rsync -av --ignore-existing --exclude=*.done --exclude=git2 --exclude=svn /home/gen-ccm-root/Downloads/ /mnt/download-mirror/
I will update this as I learn more (I am still kind of a Yocto noob), but the issue appears to be related to a combination of Yocto not reparsing after changing the config, and the fact that the sstate-cache was still accessible and said everything was there.
Wait a bit, with BB_NO_NETWORK it should not go out and fetch stuff from the internet.
If I understand it correctly you want a source mirror for some other build machines locally.
One way would be to share your DL_DIR of the one machine, which sees the internet.
Another way would be to use a source mirror for which you need the BB_GENERATE_MIRROR_TARBALLS = "1" from above.
I use a web server to export my DL_DIR (which also contains the tarballs) and on the machines which should use it I use e.g. in local.conf or site.conf:
INHERIT += "own-mirrors"
SOURCE_MIRROR_URL = "http://mirror/source_mirror_zeus"
Just as a hint besides the sources you could also export SSTATE via SSTATE_MIRRORS, which will decrease build time a lot.
I would like to replace the standard ntpd that comes with busybox with the full NTP server released in meta-openembedded.
However, I can't find the configuration or Yocto variable that sets that this version of the busybox should not have ntpd.
What is the efficient way to do this? Keep in mind that I can't edit the released Poky layer.
The way I solved is quite simple.
There was a file in my layer called busybox/files/ntpd.cfg with a flag CONFIG_NTPD. I've just set it to n and busybox was without ntpd.
I have in fact done the same to have the complete version of wget. There are 2 steps:
Configure busybox so that it does not provide such executable.
Include the recipe you located in your build.
For the first point the most elegant way is to crate a layer with its bbappend for busybox. You can follow the official example. I would initially check the default configuration. You can go faster by doing it manually like explained here. Either if you create a fragment for your bbappend or you do it manually through the bitbake -c menuconfig busybox. You can check in the sorce code what is the configuration entries that need to be modified.
The second is the easiest part, install ntp recipe either via image recipe or in your local.conf. (IMAGE_INSTALL or CORE_IMAGE_EXTRA_INSTALL variables respectively)
Try to add IMAGE_INSTALL_remove = "ntp" or PACKAGE_EXCLUDE = "ntp" to your local.conf.
I've downloaded the sources for kdesvn from the github repo as I'm thinking to look into working on an addition to the project. Now turns out, I'm not even able to properly compile the downloaded sources: I've created a directory kdesvn-build changed into it and launched cmake ../ (as described on https://github.com/KDE/kdesvn/blob/master/INSTALL-cmake) which does some stuff but then stops saying:
CMake Error: The following variables are used in this project, but
they are set to NOTFOUND. Please set them or make sure they are set
and tested correctly in the CMake files: SUBVERSION_INCLUDE_DIR
Now, I don't know what SUBVERSION_INCLUDE_DIR should be set to nor could I find it searching around the web. Anyone?
It is a directory containing svn_*.h files. If you are on Linux, you'd need to install something like subversion-dev package. On FreeBSD headers are installed with main package, and the directory is /usr/local/include/subversion-1/.
I am having an issue where a recipe i'm using no longer has the variable libdir defined. It appears to only have libdir_native.
This recipe i'm using is poco-1.7.5 for Morty from openembedded so I assume the recipe should work properly.
As a result of the missing libdir variable none of the installed files are being packaged which is screwing up my build.
In the short term i've been able to fix the problem by creating an append file which makes libdir = "${libdir_native} but this doesn't seem like it should be necessary.
The only thing I can think of is that the Bitbake.conf file is not being source properly by Bitbake (or the wrong .conf is being used).
Any suggestions would be appreciated.
Based on the comments this seems to be the problem: Poco upstream installs libraries into /usr/lib/ but the yocto packaging expects them to be in ${libdir} which may be different from /usr/lib/.
The most common reason (for cmake recipes) for this is that the upstream project does not support CMAKE_INSTALL_LIBDIR. Check if the upstream build system has some alternative means for specifying libdir -- this is surprisingly common with cmake projects. If not, you could add support for CMAKE_INSTALL_LIBDIR in the upstream build system (and add a patch to your recipe).
An alternative hack would be to add a do_install_append() that checks if ${libdir} is not /usr/lib/, and moves everything from ${D}/usr/lib/ to ${D}${libdir} in that case.