The core-image-lsb builds on the autobuilder are failing: | error: Failed dependencies: | xorg-abi-video-8 is needed by emgd-driver-1.14-r4.core2 (http://autobuilder.yoctoproject.org:8010/builders/fri2/builds/255/steps/shell_58/logs/stdio) The LSB targets don't have X, which is why the dependency on xserver-xorg (which provides the -abi- name) isn't satisfied. The better question is why emgd-driver is being installed on an image without graphics. Chasing dependencies leads to: packagegroup-base -> va-intel -> libva -> mesa-dri -> emgd-driver-bin And packagegroup-base depending on va-intel is the result of: MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}" I'm not convinced that we want to be adding the VAAPI elements at this level. Also, as the dependency is on libva->mesa-dri->emgd, it's clearly after some GL libraries, so splitting up emgd-driver-bin into libegl-emgd, libgles1-emgd and xf86-video-emgd will mean that the image will just pull in the GL packages and not the X driver.
I tried building core-image-lsb for crownbay bsp here with current master branches, and I am getting different error. | error: Failed dependencies: | pkgconfig is needed by libz-dev-1.2.7-r0.core2
his seems to be related to Bug 3373 - meta-intel: VA_FEATURES unnecessarily causes X11 dependency via libva: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3373 i.e. we should be able to bring in libva and not not have the dependency on X but currently we can't do that as explained in 3373. We should also be able to turn off video acceleration and therefore not bring in libva via emgd-driver-bin, but can't do that either as explained in Bug 2551 - EMGD requires video acceleration: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2551 So separating the video components out of emgd-driver-bin into a separate package was how we planned on fixing that. Until now we haven't had build problems with this - obviously something in master has changed, and so this either needs to be fixed in master or fixed according to the above bugs or in some other completely different way as the above comment suggests...
Reverting the commit "emgd-driver-bin: add xorg-abi-video- dependency" commit fa655a783bc1e41109f408ff49b785d664f64106 gets rid of this build error in core-image-lsb (though the pkgconfig error still remains), which doesn't seem correct in the first place - if anything, shouldn't it be xorg-video-abi rather xorg-abi-video? I don't see why this should be a problem in the first place, since we already pin the emgd-using machines to xserver-xorg 1.9.3 and that should still be the same - nothing related to the upgrade to the new xorg-xserver should change this and I'd guess that the problem lies in the packaging changes made to the xserver include. We do need changes to separate the video components mentioned previously and in the already-existing bugs for that, but that shouldn't be causing problems for the existing BSPs and emgd support tied to 1.9.3. The commit message for a patch to revert sent to the mailing list is below. The above commit is causing build problems that this revert fixes e.g.: | error: Failed dependencies: | xorg-abi-video-8 is needed by emgd-driver-1.14-r4.core2 Fixes [YOCTO #3507]. There's no explanation of what the actual problem was that this commit fixes - likely it was in response to the packaging problems causing YOCTO #3501 and YOCTO #3502. In any case, nothing should cause a regression like this since xserver-xorg is pinned at 1.9.3 and its contents shouldn't change to cause something like 'xorg-abi-video' to disappear. Also there doesn't appear to any xorg-abi-video-8, so it's doubtful that this commit actually fixed the problem it was trying to fix -
OK, so Ross's oe-core patch: [PATCH] xserver-xorg: restore packaging for the DRI/DRI2/DBE extensions does work if Nitin's patch: [PATCH 1/4] meta-intel.inc: fix xorg packaging issue for emgd BSPs is added to meta-intel. That fixes this bug (3502) and also should fix Bug 3501 and 3502. I've also submitted another patch to meta-intel [PATCH 1/1] Revert "emgd-driver-bin: add xorg-abi-video- dependency" that reverts Ross's fa655a783bc1e41109f408ff49b785d664f64106 xorg-abi-video-8 patch and thereby gets rid of the core-image-lsb build error and fixes bug 3507. So if we can get Ross's oe-core patch pulled in, I can pull in the other two and we'll be able to move forward. Otherwise, someone please suggest something better to get us out of this mess.
BTW, I did test video playback with dictator.mp4 after building with all those fixes and it worked fine .
My mistake - xorg-abi-video does exist and some explanation behind the reason for the xorg-abi-video commit in meta-intel can be found on the oe-core list and further explanation from the meta-intel mailing list from Ross is copied below: ross@melchett /data/poky-master/tmp/work/core2-poky-linux/xserver-xorg/1_1.9.3-r2/deploy-ipks/core2 $ dpkg -I xserver-xorg_1.9.3-r2_core2.ipk ... Provides: xorg-abi-video-8, xorg-abi-input-11 There was a thread on oe-core and the relevant oe-core commits had plenty of explanation: commit bc41dfb9cd2d3b90d97fa051c90d2f53bacde059 Author: Ross Burton <ross.burton@intel.com> Date: Mon Oct 22 10:37:24 2012 +0100 xserver-xorg: add runtime provides for the driver ABI version The xserver driver ABIs can and do change in a way that is unrelated to the version of xserver, so it's entirely possible to build an image that has a mismatch between the server ABI version and the version that the drivers were built against. xserver detects this and refuses to load the modules. By adding RPROVIDEs to the xserver package that describe the ABI versions it has (such as xorg-abi-video-13, xorg-abi-input-11), drivers can RDEPEND on the version that they were built against. This means that when the ABIs change, there will be package dependency errors at image time instead of images that build fine but don't work. (From OE-Core rev: 8ef5f205aec04140198d5ba0f5c405ae6e977dbe) You may have pinned xserver-xorg in the bitbake to 1.9.3 but: 1) it's entirely possible for the package feed to get 1.13 from another MACHINE, because they'll both be in the "core2" arch feed 2) it's enforcing the ABI relationship which can't be expressed in any other way
Where are we with this? Are we going to make M2?
I told Nitin I'd look into it, but haven't gotten time yet - I will be looking into it soon however. It should definitely make M2 (Jan 11). There's also a fallback if we want to get the lsb build temporarily building again, which is to temporarily revert Ross's xorg-abi-video- dependency and temporarily ignore the package feed issue mentioned by Ross.
I have not spent much time on this yet. I will sync up with Tom on this. and I too think that we should be able to close it in M2.
So, looking at the actual build directories on the autobuilder, we see the following error saying it can't find the git directory in the workdir: tomz@yocto-iab09:/srv/home/pokybuild/yocto-autobuilder/yocto-slave/cedartrail/build/build/tmp/work/cedartrail-poky-linux/lttng-modules/2.0.5-r0/temp> less log.do_make_scripts /srv/home/pokybuild/yocto-autobuilder/yocto-slave/cedartrail/build/build/tmp/work/cedartrail-poky-linux/lttng-modules/2.0.5-r0/temp/run.do_make_scripts.27949: line 113: cd: /srv/home/pokybuild/yocto-autobuilder/yocto-slave/cedartrail/build/build/tmp/work/cedartrail-poky-linux/lttng-modules/2.0.5-r0/git: No such file or directory But listing it shows it's in fact there: tomz@yocto-iab09:/srv/home/pokybuild/yocto-autobuilder/yocto-slave/cedartrail/build/build/tmp/work/cedartrail-poky-linux/lttng-modules/2.0.5-r0/temp> ls -al /srv/home/pokybuild/yocto-autobuilder/yocto-slave/cedartrail/build/build/tmp/work/cedartrail-poky-linux/lttng-modules/2.0.5-r0/git total 352 drwxr-xr-x 9 pokybuild users 4096 Dec 13 06:58 . drwxrwxrwx 6 pokybuild users 4096 Dec 13 06:58 .. -rw-rw-rw- 1 pokybuild users 7042 Dec 13 06:58 ChangeLog drwxrwxrwx 8 pokybuild users 4096 Dec 13 06:58 .git -rw-rw-rw- 1 pokybuild users 936 Dec 13 06:58 .gitignore -rw-rw-rw- 1 pokybuild users 17987 Dec 13 06:58 gpl-2.0.txt drwxrwxrwx 4 pokybuild users 4096 Dec 13 06:58 instrumentation -rw-rw-rw- 1 pokybuild users 26434 Dec 13 06:58 lgpl-2.1.txt drwxrwxrwx 4 pokybuild users 4096 Dec 13 06:58 lib -rw-rw-rw- 1 pokybuild users 689 Dec 13 06:58 LICENSE -rw-rw-rw- 1 pokybuild users 20571 Dec 13 06:58 lttng-abi.c -rw-rw-rw- 1 pokybuild users 4851 Dec 13 06:58 lttng-abi.h -rw-rw-rw- 1 pokybuild users 1178 Dec 13 06:58 lttng-calibrate.c -rw-rw-rw- 1 pokybuild users 2924 Dec 13 06:58 lttng-context.c So it is actually there, but apparently it wasn't when that task (run_do_make_scripts) was run, which means we probably have a race.
oops, ignore the previous comment, wrong bug.
a patch sent to meta-intel ML which will fix this bug. - Nitin
Fixed by meta-intel commit: 3d00ac1da6c2a1013a7cfc03d7ea94274bf6731a
*** Bug 3631 has been marked as a duplicate of this bug. ***
Autobuilder shell for a core-image-lsb nightly-x86-64-lsb: Build Configuration: BB_VERSION = "1.17.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "SUSE-LINUX-11.4" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky-lsb" DISTRO_VERSION = "1.3+snapshot-20130207" TUNE_FEATURES = "m64" TARGET_FPU = "" meta meta-yocto = "master:8c263420eda2c2ab0e6f8bff64f965cb4cc5698b" meta-qt3 = "master:06e2fe600de962cdba53c23de1207501439a9c9f" meta-yocto-bsp = "master:8c263420eda2c2ab0e6f8bff64f965cb4cc5698b" Summary: There were 2 WARNING messages shown. program finished with exit code 0