There are some problems while building an image sdk together with deb packaging system. I'm using SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs" to add automatically all -dev and -dbg packages of the packages from the image into the sdk. To make apt actually try installing this packages I actually had to do some changes to poky/meta/lib/oe/sdk.py (see #7160). After that, I can see in log.do_populate_sdk that it tries to install all the dev packages, but when trying to install them, APT fails because it says some dependencie sfor some packages are broken because the deps are not going to be installed. For instance, in IMAGE_INSTALL I have some gstreamer stuff. Gstreamer dev packages depend on pulseaudio-dev which in turn depends on avahi-dev, which in turn automatically depends on "avahi" package (which by the way only contains a /var empty directory for what I could see). But as avahi is not in my IMAGE_INSTALL var, apt doesn't want to install it to the sdk and then installation of the dev packages is not happening. I could fix it by running apt-get install -f after installing packages by modifying DpkgPM, but that's not the right way of doing it, as in fact it's hiding some important errors among packages being installed. what do you think is the best approach to solve that? do you consider that a bug on bitbake? or on the recipes side? I got this response from IRC: bluelightning_ pespin: it would be a bug in the metadata, but I'm unsure of the exact correct fix bluelightning_ the first thing to do would be to file a bug in bugzilla, if you wouldn't mind
Created attachment 2328 [details] log.do_populate_sdk I attach the log.do_populate_sdk which shows whick packages are failing due to which dependencies. Hope this will be enough to point you to the right direction.
Hi Pau, I'm trying to reproduce the issue but i can't, i built core-image-sato-sdk. Here is my local.conf: MACHINE ??= "qemux86" IMAGE_INSTALL += "gstreamer1.0-plugins-base" # for this i'm using meta-gstreamer10 [1] PACKAGE_CLASSES ?= "package_deb" EXTRA_IMAGE_FEATURES = "dev-pkgs dbg-pkgs debug-tweaks package-management" SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs" Any missing option? Kind regards, alimon [1] http://layers.openembedded.org/layerindex/branch/master/layer/meta-gstreamer10/
Hi Aníbal, I was able to workaround this. First of all, I needed to add this to avahi.inc: + # Fix in place instead of using bbappend, since this is already fixed in current yocto master: + rmdir --ignore-fail-on-non-empty ${D}/var This is already fixed too in some newer version of poky, so no worries there. The consequence of this change is that now the "avahi" package is completelly empty so it is not generated, and then the dependency for that package doesn't exist. For the rest of the packages, I had to add this to my image, which forces the dependencies to be included into the SDK and so I think it's an ugly hack: +#Hack: Manually add to SDK some dependencies of some -dev complementary packages which are installed into the SDK. +#If not done, apt will fail to install all complementary packages due to dependency errors (as they are not in IMAGE_INSTALL) +TOOLCHAIN_TARGET_TASK += " alsa-state e2fsprogs kbd cairo gnutls opkg-utils " + Some more hitns which may help you: 1- I see you added gstreamer1.0-plugins-base to the image, but in my case the one giving problems is gstreamer1.0-plugins-bad 2- I am also using meta-renesas, meta-ivi and meta-qt layers. 3- Using wayland/weston and gles. 4- TOOLCHAIN_HOST_TASK += " nativesdk-qtbase-tools-dev " 5- IMAGE_INSTALL += " alsa-utils alsa-lib alsa-tools pulseaudio connman" 6- # Qt IMAGE_INSTALL += " qtbase qtbase-fonts-qpf qtwayland qtwayland-plugins qtwayland-tools " IMAGE_INSTALL += " qtdeclarative qtdeclarative-qmlplugins qtdeclarative-tools qtquickcontrols-qmlplugins " IMAGE_INSTALL += " hellogles2 animatedtiles helloqt5 " IMAGE_INSTALL += " liberation-fonts kbd-consolefonts qtbase-fonts-pfa fontconfig-utils qtbase-fonts qtbase-fonts-ttf-dejavu qtbase-fonts-pfb qtbase-fonts-ttf-vera " Sorry for not being able to give you the complete env, but I guess I'm not allowed to do that because it's not my personal project.
Anibal, It appears that the information was provided.
Created attachment 2492 [details] log from do_populate_sdk on the vmware machine target
It seems similar problem is happening now when trying to build the SDK for vmware machine. I attached relevant parts of the log.do_populate_sdk file
In this case it seems at the end the responsible of the whole error was this one: packagegroup-foobar-common-minimal : Depends: mesa but it is not going to be installed It seems the mesa package was a package containing only an empty "/etc/" directory afterall, and I was able to remove it from the packagegroup without problems. After that, all package dependencies are fixed magically, or at least they don't output error and the whole pack of packages are installed into the SDK. Anyway, something's wrong to me. Why did it say "Depends: mesa but it is not going to be installed" ? Because it should, the mesa package was in IMAGE_INSTALL through that packagegroup. Adding it to TOOLCHAIN_TARGET_TASK didn't help neither. About the mesa package containing /etc only, looking at the recipe in master I think it's still like that and not fixed. I will look into it now and add possible patch.
Created attachment 2493 [details] patch to avoid leaving empty sysconfdir in mesa package It applies to poky 1.6.1, but I see the same install_append is still used for poky master, so it should be useful in there too.
Hi Pau, Thanks for all the information, i'll review it. (In reply to comment #8) > Created attachment 2493 [details] > patch to avoid leaving empty sysconfdir in mesa package > > It applies to poky 1.6.1, but I see the same install_append is still used > for poky master, so it should be useful in there too. Can you send this patch to the mailing list with [Daisy] prefix? Cheers, alimon
Hi, sorry for the delay, I missed your request regarding the mailing list. I sent the patch (a bit improved) to the oe-core mailing list and I added you in CC. The mail is called "mesa: Avoid leaving empty sysconfdir in mesa package"
I found out I had a similar issue with an own recipe as I had with mesa, which was now preventing the SDK successful installation. So far, I think there are 2 separate issues: 1) The sdk apt installation fails when your image depends on a package which only contains an empty directory. So for, instance, your package only contains directory "/etc/udev/rules.d" but no files inside it. It seems apt fails to check/install that package and then it cries silently (only seen inside the log file) about missing dependencies (huge list of dependency issues is shown but actually only one of them is actually the one making the installation process to fail, as shown in some log file before). I think with this steps you should be able to reproduce these issues: * Create a recipe recipeA which creates packageA which contains only directory "/etc/udev/rules.d" with no file in it. * Create a recipeB which depends on packageA and creates packageB * Create an imageA with IMAGE_INSTALL += packageB * Build the imageA and its sdk * Check log.do_populate_sdk. I guess you should have the dep error in there. I guess you don't even need all the recipeB/packageB to get the error. Possible Solutions: - Make bitbake check and output an error when a package with an empty directory is created when using deb, because it seems apt doesn't like it?. - When SDK is being build and this kind of error appears, actually output the error to the user and mark the build as failed. - Fix apt to stop failing in this kind of scenario (as in resolving deps when a package with only an empty directory is found). 2) $PN-dev package is set to automatically RDEPEND on $PN, but it seems to me that actually that dependency is set in $PN-dev without checking if $PN is going to be actually built. That ends up in broken dependencies if $PN is not built, and it fails silently on the deb sdk generation without marking the build as failed. I guess this can be reproduced following something similar than this: * Create a recipeA which ends up generating a usual packageA-dev package, but make all packageA files actually go into for example packageA-server. That means packageA is not going to be generated, but packageA-dev will depend on packageB. * Create a recipeB which depends on packageA-server and creates packageB * Create an imageA with IMAGE_INSTALL += packageB * Build the imageA and its sdk * Check log.do_populate_sdk. I guess you should have the dep error in there. In this case, I guess the recipeB/packageB stuff is note even needed as I think the SDK just takes all *-dev packages and tries to install them. Possible Solutions: - Ensure that when the RDEPENDS+="$PN" is added in $PN-dev, $PN is going to be built/exist. - When SDK is being build and this kind of error appears, actually output the error to the user and mark the build as failed.
(In reply to comment #11) > I found out I had a similar issue with an own recipe as I had with mesa, > which was now preventing the SDK successful installation. > > So far, I think there are 2 separate issues: > > 1) > The sdk apt installation fails when your image depends on a package which > only contains an empty directory. So for, instance, your package only > contains directory "/etc/udev/rules.d" but no files inside it. It seems apt > fails to check/install that package and then it cries silently (only seen > inside the log file) about missing dependencies (huge list of dependency > issues is shown but actually only one of them is actually the one making the > installation process to fail, as shown in some log file before). > > I think with this steps you should be able to reproduce these issues: > > * Create a recipe recipeA which creates packageA which contains only > directory "/etc/udev/rules.d" with no file in it. > * Create a recipeB which depends on packageA and creates packageB > * Create an imageA with IMAGE_INSTALL += packageB > * Build the imageA and its sdk > * Check log.do_populate_sdk. I guess you should have the dep error in there. > > I guess you don't even need all the recipeB/packageB to get the error. > > Possible Solutions: > - Make bitbake check and output an error when a package with an empty > directory is created when using deb, because it seems apt doesn't like it?. > - When SDK is being build and this kind of error appears, actually output > the error to the user and mark the build as failed. > - Fix apt to stop failing in this kind of scenario (as in resolving deps > when a package with only an empty directory is found). If you want to generate a empty package need to specify ALLOW_EMPTY [1] into recipe because if isn't specified the package isn't generated. > > > 2) > $PN-dev package is set to automatically RDEPEND on $PN, but it seems to me > that actually that dependency is set in $PN-dev without checking if $PN is > going to be actually built. That ends up in broken dependencies if $PN is > not built, and it fails silently on the deb sdk generation without marking > the build as failed. > > I guess this can be reproduced following something similar than this: > * Create a recipeA which ends up generating a usual packageA-dev package, > but make all packageA files actually go into for example packageA-server. > That means packageA is not going to be generated, but packageA-dev will > depend on packageB. > * Create a recipeB which depends on packageA-server and creates packageB > * Create an imageA with IMAGE_INSTALL += packageB > * Build the imageA and its sdk > * Check log.do_populate_sdk. I guess you should have the dep error in there. > > In this case, I guess the recipeB/packageB stuff is note even needed as I > think the SDK just takes all *-dev packages and tries to install them. > > Possible Solutions: > - Ensure that when the RDEPENDS+="$PN" is added in $PN-dev, $PN is going to > be built/exist. > - When SDK is being build and this kind of error appears, actually output > the error to the user and mark the build as failed. Seems to me the same case as the another if you expect an empty package need to set ALLOW_EMPTY [1] in order to generate it. [1] http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#var-ALLOW_EMPTY
Hi, I don't agree with your resolution, or at least with the logic behind it. First of all, please, note in my last comment description that the package is not empty and actually it gets generated, as it has an empty directory in it. After that, when it gets installed it fails though. Even if you consider this should be an expected behavior (like incorrect recipe), then for sure if there's an apt error while installing the packages for the sdk, bitbake should output that error and stop the build with exit!=0, as the task was not completed correctly.