Re: [yocto] Eclipse plugin plans
The same as it is now. The CROPS Docker containers already support that. https://github.com/crops/docker-win-mac-docs/wiki On Mon, Jan 29, 2018 at 8:25 PM Trevor Woerner wrote: > Just to clarify... will non-IDE non-Linux development be explicitly > supported? > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Eclipse plugin plans
Just to clarify... will non-IDE non-Linux development be explicitly supported? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto] clutter-CRITICAL **: Unable to initialize clutter: Unable to Initialize the clutter backend: no available drivers found.
On 01/29/2018 09:47 PM, kishorepasupula wrote:
>
> Hi,
> As per my understanding I’m not using any proprietary drivers. And
> Graphic recipies being used are from meta layer itself.
>
> Here is my complete setup.
>
> 1) Created a custom layer (4.9.73) for Beaglebone Black instead of
> using yocto-kernel(This is the only custom layer I have created rest are
> standard I.e meta, meta-poky, meta-yocto-bsp)
> -Here is the recipie for custom kernel( https://pastebin.com/w4GXbY6w )
> -local.conf file ( https://pastebin.com/fp2XaxFE )
> -I have Interfaced LCD display(4D 4.3” LCD cape) to my Beaglebone
> Black.
> -Here is the defconfig file :(Attached to Email)
> -Enabled following fields in menuconfig:
> Device Driver→Graphics support
>
> ->Direct Rendering
> →DRM Support for TI LCDC Display
> Controller
> →Support device tree blobs using TI
> LCDC Slave binding
> -Machinefile( https://pastebin.com/T4YesHx3 )
You're probably not using the correct user space DRI driver and/or xorg
configuration. Maybe check out meta-ti layer to see if that works ...
Thanks,
Anuj
>
>
> 2) Though build was successful. After porting “Snappy” application when
> I tried to run “snappy” application on target I.e BeagleBone Blak, we
> are getting error response as addressed in previous mail.
>
> 3)Boot log of BeagleBone black( https://pastebin.com/26FaeBvw )
>
> Please let me know if you need any further information from my end.
>
> Regards,
> kk.
>
> On 01/29/2018 02:48 PM, Anuj Mittal wrote:
>> On 01/29/2018 01:05 PM, kishorepasupula wrote:
>>>
>>> Hi,
>>>
>>> My main objective is to run snappy player
>>> (https://wiki.gnome.org/Snappy) on target machine (BeagleBone Black) so,
>>> I wrote a recipe for Snappy player(snappy_1.0.bb) as below
>>>
>>> LICENSE = "GPLv2"
>>> LIC_FILES_CHKSUM = "file://COPYING;md5=686e6cb566fd6382c9fcc7a557bf4544"
>>>
>>> SRCREV = "e73fabce4c397b40d490c74f6a6a0de000804f42"
>>> SRC_URI = "git://git.gnome.org/snappy"
>>> S = "${WORKDIR}/git"
>>>
>>> RDEPENDS_${PN} = "gtk+3 gstreamer1.0 glib-2.0 clutter-1.0
>>> gstreamer1.0-plugins-base libxtst clutter-gst-3.0 clutter-gtk-1.0 libx11
>>> cairo gdk-pixbuf"
>>>
>>> # inherit line
>>> inherit pkgconfig autotools
>>>
>>> FILES_${PN} += "${datadir}/*"
>>> Added this recipe name in local.conf
>>>
>>> IMAGE_INSTALL_append = " snappy"
>>> The build (bitbake core-image-sato) was successful, when I ran "snappy"
>>> on target(BeagleBone Black) I am getting below error response.
>>>
>>> sh-4.4# snappy
>>> libEGL warning: DRI2: failed to authenticate
>>> libEGL warning: DRI2: failed to authenticate
>>> libEGL warning: DRI2: failed to authenticate
>>>
>>> (snappy:763): clutter-CRITICAL **: Unable to initialize clutter: Unable
>>> to Initialize the clutter backend: no available drivers found.
>>>
>>> As per my Understanding in my recipe I have resolved all dependencies
>>> for Snappy player (such as clutter, gstreamer, gtk etc.). I'm unable to
>>> figure out why snappy player is throwing error? Can any one guide me on
>>> this?
>>>
>>> PS: Also tried adding PREFERRED_PROVIDER_virtual/egl ?= "mesa" in
>>> local.conf but still I'm getting the same error response.
>>
>> Are you using proprietary drivers? If libegl is coming from mesa, it
>> will probably not work with proprietary drivers. Can you provide more
>> details about your setup? Which layer(s) are you using etc. and where
>> are the graphics recipes/drivers coming from?
>>
>> Thanks,
>> Anuj
>>
>>>
>>> Regards,
>>> Kk.
>>>
>>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Eclipse plugin plans
Hi all, I've recently become involved in development of our Eclipse integration, and we figured it's about time we sent out an update on where things currently stand. Current development --- New life is being injected into the Yocto Project Eclipse plugins. There are several drivers for this: 1) Integrate the tooling with Docker. With changes and additions to Eclipse CDT and Eclipse Linuxtools projects, it’s now possible to have Docker images provide functionality that’s running within Eclipse. For example, CDT’s autotools can be run in a Docker container for compiling/building/recipe and for running/debugging. 2) Docker tooling also provides a way to do cross-OS building/running - e.g. Eclipse running on Windows doing compiles/running/recipes for a target running on Linux (in a Linux Docker Container). Up until now we have been restricted to Linux as the Eclipse host OS. We will be looking at Windows first, MacOS may follow later. 3) Simplify the deployment and installation of the plugins. Currently, the plugins have a number of dependencies…e.g. on Eclipse CDT and others. This often makes it difficult to install, use, and upgrade the plugins, particularly for Yocto Project beginners. 4) Update the plugins for latest Eclipse. Eclipse has upgraded its support (CDT, Linuxtools/Docker, etc) significantly, and the plugins do not yet take advantage of these improvements. The target for the 2.6 release will likely be Eclipse Photon (released June 2018). 5) Improve and make more transparent the Build/Continuous Integration/Release Engineering for the plugins. This will make it easier for others to contribute, and will make it easier for automated testing to be done improving overall quality. To start down these directions and explicitly start on 3, 4, 5 we propose that for eclipse-poky we move toward a maven-based build. Maven-based builds are extremely common in the Eclipse plugin development world, and there are a lot of technologies openly available to support building these plugins: e.g. maven, tycho, Eclipse itself. As part of this we will be looking to transition the autobuilder from the current script-based build to a maven-based build, but with two caveats: a) the current autobuilder will be used for 2.5 release b) both builds (script-based) and maven-based will be maintained until after 2.5 release c) the maven-based build will add: automated testing, easier dependency management, a more open and maintainable build system We are proposing that the existing eclipse-poky 2.5 branch (oxygen.master) be soon frozen (after a few small pending fixes) and that the eclipse-poky ‘master’ be opened up for 2.6 development. This way we will have a stable release candidate as 2.5 approaches, and be able to begin work on 1-5 as above for 2.6 as soon as possible. If you want a peek at what we are currently working on with maven see the timo/maven branch in eclipse-poky-contrib. New instructions are in the README.dev file. A note about CROPS The earlier effort to build the CROPS architecture to support multiple IDEs has been dropped - unfortunately we weren't able to realise the original design for a number of reasons including that in the case of Eclipse it was incompatible with the upstream Eclipse direction. We have now switched back to the original eclipse-poky codebase and are following upstream Eclipse / Linuxtools / CDT development a lot more closely. We will however gain some of the features that CROPS set out to provide - i.e. building in a container and therefore enabling the IDE to be running on a non-Linux OS. Note: the CROPS containers [1] are still around and functional, and will likely form the basis of the containers used by the current YP Eclipse plugins. New mailing list - As you may have seen elsewhere, we now have a mailing list dedicated to Eclipse plugin development and related discussion. You can find information (and list archives) here: https://lists.yoctoproject.org/listinfo/eclipse-poky If you have follow-up questions / discussion or would like to get involved, please join us over on that list. Cheers, Paul [1] https://wiki.yoctoproject.org/wiki/TipsAndTricks/CropsCLIContainers -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fetching from local repostories
We are storing some of the source code locally on a machine. Found
this on how to do it, https://stackoverflow.com/a/27834916/1636521,
but for some reason it doesn't work for me. I'm pretty sure I'm
missing something but don't know what exactly.
Here is my recipe
SUMMARY = ""
DESCRIPTION = ""
# Licensing Meta-data
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""
# Modify these as desired
PV = "1.0+git${SRCPV}"
SRCREV = "${AUTOREV}"
S = "${WORKDIR}/git"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "\
file://app.tgz \
"
DEPENDS += "\
libevent \
"
do_compile () {
export SWROOT=${S}/../app
oe_runmake
}
do_install () {
:
}
And here is the error that I'm getting:
Loading cache: 100%
|###|
Time: 0:00:01
Loaded 3265 entries from dependency cache.
WARNING:
/home/user/projects/petalinux-build-system/sources/core/../meta-piccard/recipes-piccard/cpe/cpe.bb:
Unable to get checksum for cpe SRC_URI entry app.tgz: file could not
be found
Parsing recipes: 100%
|#|
Time: 0:00:04
Parsing of 2476 .bb files complete (2470 cached, 6 parsed). 3269
targets, 229 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS= "arm-xilinx-linux-gnueabi"
MACHINE = "zynq-generic"
DISTRO= "petalinux"
DISTRO_VERSION= "2017.3"
TUNE_FEATURES = "arm armv7a vfp thumb neon
callconvention-hard cortexa9"
TARGET_FPU= "hard"
meta
meta-poky = "HEAD:8506cec55de8950e89a4d3e786860f1086782587"
meta-perl
meta-systemd
meta-gpe
meta-python
meta-efl
meta-ruby
meta-filesystems
meta-gnome
meta-multimedia
meta-networking
meta-webserver
meta-xfce
meta-initramfs
meta-oe = "HEAD:a9887ac249b81fcac3007244d0c807c71b73acef"
meta-linaro-toolchain = "HEAD:39860f6c7af0858981cc004bbe4f4c421f6be607"
meta-qt5 = "HEAD:eec778bfb9a0b5494d593a2d7bb02c027b641835"
meta-xilinx = "HEAD:04a45809e0bc42b35c88f8a08305d82fd25e97cf"
meta-xilinx-tools = "HEAD:37eff634934efac72d3e2eabb7c4f8d0c8a36fbb"
meta-petalinux= "HEAD:d74ceaef26e606c2761edfc3446d0ad3c3cc8b8e"
meta-virtualization = "HEAD:cbfd4376d5e9d229f857151ffdfb57fbc6c0c40d"
meta-openamp = "HEAD:cfeca8988418e4967f0d6df828d23a1540ae25a0"
meta-swupdate = "HEAD:6c066d36b1c3c6d46f16c09efe5fb7681bbf3dc5"
meta-piccard = "master:9f114a33df76a3c3f40eca12b7195ff8ebaad876"
workspace = "HEAD:51fa75c5477e29285bbbe810f4327b26d80d511d"
Here is the ls of the recipes directory,
$ ls
~/projects/petalinux-build-system/sources/meta-piccard/recipes-piccard/cpe/files
app app.tgz
The output of
bitbake cpe -e | grep FILESEXTRAPATHS
produces the following line
FILESEXTRAPATHS="/home/userl/projects/petalinux-build-system/sources/core/../meta-piccard/recipes-piccard/cpe/files:__default:"
What am I missing?
--
Rail Shafigulin
Software Engineer
Esencia Technologies
--
*ESENCIA TECHNOLOGIES, INC.*2350 Mission College Blvd. Suite #490
Santa Clara CA 95054
Phone: +1 408 736 8284 Fax: +1 408 519 3475
http://www.esenciatech.com | http://www.lnttechservices.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error running testimage under the autobuilder with pyro branch
On 29/01/2018 07:44, Alexander Kanavin wrote: On 01/28/2018 04:57 PM, Alex Lennon wrote: Hi all, I've got some simple automated testing going to test meta-mono core-image-mono builds. It just bitbakes the image then runs the testimage command This works fine for master and rocko branches, but I get a failure for pyro Exception: TypeError: Test oeRuntimeTest is not derived from OERuntimeTestCase The rest of the log is here: https://pastebin.com/NRVLLtsF Can anybody point me towards what might have changed between branches / where I'm going wrong? This has been refactored between rocko and pyro. You need to create a separate pyro branch for your tests, check how those look in pyro oe-core, and modify them accoridngly. Alex OK - thanks for that Alex. Cheers, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] ref-manual: Document the task feature of BUILDHISTORY_FEATURES
Signed-off-by: Peter Kjellerstedt --- documentation/ref-manual/ref-variables.xml | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml index 521eaeaed2..70e5e3428b 100644 --- a/documentation/ref-manual/ref-variables.xml +++ b/documentation/ref-manual/ref-variables.xml @@ -1927,8 +1927,8 @@ -You can specify three features in the form of a -space-separated list: +You can specify features in the form of a space-separated +list: image: Analysis of the contents of images, which @@ -1942,12 +1942,17 @@ Analysis of the contents of the software development kit (SDK). +task: +Save output file signatures for sstate tasks. This +saves a file per task listing the SHA-256 checksums +for each file staged, i.e., the output of the task. + By default, the buildhistory class -enables all three features: +enables the following features: BUILDHISTORY_FEATURES ?= "image package sdk" -- 2.12.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW05’18
Current Dev Position: YP 2.5 M2 development Next Deadline: YP 2.5 M2 cut off was 1/15/18 SWAT team rotation: Ross -> Juro on Jan. 26, 2018. SWAT team rotation: Juro -> Tracy on Feb. 2, 2018. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · YP 2.5 M1 rc3 was released. · Fixes for spectre and meltdown are in master and also in the rocko branches for both gcc (updated to 7.3) and linux-yocto. · We will likely consolidate a few further patches (such as genericx86 and other meta-yotcto-bsp updates) and then build and QA both 2.5 M2 and 2.4.2. · Work on the autobuilder changes continues but means autobuilder.yoctoproject.org is not being used in production (autobuilder.yocto.io aka ‘the new cluster’) is. · There were a number of lock related issues with the yocto.io builder over the weekend which are being investigated. Planned upcoming dot releases: YP 2.4.2 (Rocko) will be built shortly. YP 2.3.4 (Pyro) will be built when a stable version of the spectre/meltdown patches are ready. YP 2.2.3 (Morty) rc1 is in QA, see https://wiki.yoctoproject.org/wiki/2.2_QA_Status. This will not contain the spectre/meltdown patches as they’re not ready yet. Key YP 2.5 Dates are: YP 2.5 M2 cut off is past, it should be built shortly. YP 2.5 M2 release of 1/26/18 YP 2.5 M3 cut off of 2/19/18 YP 2.5 M3 release of 3/2/18 YP 2.5 M4 cut off of 4/2/18 YP 2.5 M4 release of 4/27/18 Tracking Metrics: WDD 2630 (last week 2657) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 • Work Telephone:(503) 712-0534 •Cell: (208) 244-4460 • Email:stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] Glibc 2.27
On 01/29/2018 06:16 AM, Burton, Ross wrote: > On 29 January 2018 at 13:56, Zoran Stojsavljevic > mailto:zoran.stojsavlje...@gmail.com>> > wrote: > > > Khem Raj writes: This has gotten limited testing. > > Burton Ross writes: This one will be easy to integrate. > > Time Will Tell. > > > I guess I meant easy in that it just won't be going to stable > releases. Obviously integration of a new C runtime release into > master is never objectively easy. We update tend to update some if not all the toolchain components at least once between releases. So far, the small team of folks who clean up any issues with these updates have been successful. - Armin > > Ross > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] Glibc 2.27
On 29 January 2018 at 13:56, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > > Khem Raj writes: This has gotten limited testing. > > Burton Ross writes: This one will be easy to integrate. > > Time Will Tell. > I guess I meant easy in that it just won't be going to stable releases. Obviously integration of a new C runtime release into master is never objectively easy. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] Glibc 2.27
> Khem Raj writes: This has gotten limited testing. > Burton Ross writes: This one will be easy to integrate. Time Will Tell. Zoran ___ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Glibc 2.27
The yocto autobuilder was idle so I fired it, fingers crossed :) On 27 January 2018 at 21:44, Khem Raj wrote: > Hi All > > glibc 2.27 is releasing soon in few weeks. I have put together the recipes > for upgrade, along with fixes for some of packages that I ran into here > > http://git.openembedded.org/openembedded-core-contrib/log/? > h=kraj/glibc-2.27 > > This has gotten limited testing. I plan to put the package fixes as we > plough through. Please test this out in your setups and report problems or > fixes ( preferred ) to get various packages working on 2.27 release > > Thanks > -Khem > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] Glibc 2.27
On 29 January 2018 at 07:45, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > This one will be tough to integrate. Most of the packages depend on > this one, which is critical one. On the very bottom. I would say, this > is a big step, since here somewhere you should draw clear line. And > this line will be the following: which releases you/YOCTO crew will > support (back-port to) with Glibc 2.27, and which not?! > This one will be easy to integrate: it goes into master and none of the stable releases. Stable releases only get upgrades after release is very limited situations. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] opkg-build: improve package reproducibility
Implements some of the recommendations by reproducible-build.org [1]
- Set modification time to SOURCE_DATE_EPOCH env variable
- Enable deterministic sorting of directory entries
- Do not save timestamp on gzip compressed archive
bugzilla #11242
[1] https://reproducible-builds.org/docs/archives/
Signed-off-by: Alejandro del Castillo
---
opkg-build | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/opkg-build b/opkg-build
index 0fe513a..7bfdd99 100755
--- a/opkg-build
+++ b/opkg-build
@@ -149,6 +149,7 @@ outer=ar
noclean=0
opkext=0
compressor=gzip
+compressorargs="-9n"
# Determine if tar supports the --format argument by checking the help output.
#
@@ -222,6 +223,15 @@ done
cext=$(compressor_ext $compressor)
+if [ $compressor = "gzip" ] ; then
+ # pgzip requires -T to avoid timestamps on the gzip archive
+ if gzip --help 2>&1 | grep -- "-T" > /dev/null; then
+ compressorargs="-9nT"
+ fi
+else
+ compressorargs=""
+fi
+
shift $(($OPTIND - 1))
# continue on to process additional arguments
@@ -267,9 +277,11 @@ fi
tmp_dir=$dest_dir/IPKG_BUILD.$$
mkdir $tmp_dir
+build_date="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}"
+%Y-%m-%d)"
+
echo $CONTROL > $tmp_dir/tarX
-( cd $pkg_dir && tar $ogargs -X $tmp_dir/tarX -c --$compressor $tarformat -f
$tmp_dir/data.tar.$cext . )
-( cd $pkg_dir/$CONTROL && tar $ogargs -cz $tarformat -f
$tmp_dir/control.tar.gz . )
+( cd $pkg_dir && tar $ogargs --sort=name --mtime=$build_date -X $tmp_dir/tarX
-c $tarformat . | $compressor $compressorargs > $tmp_dir/data.tar.$cext )
+( cd $pkg_dir/$CONTROL && tar $ogargs --sort=name --mtime=$build_date -c
$tarformat . | gzip $compressorargs > $tmp_dir/control.tar.gz )
rm $tmp_dir/tarX
echo "2.0" > $tmp_dir/debian-binary
@@ -284,7 +296,7 @@ rm -f $pkg_file
if [ "$outer" = "ar" ] ; then
( cd $tmp_dir && ar -crf $pkg_file ./debian-binary ./control.tar.gz
./data.tar.$cext )
else
- ( cd $tmp_dir && tar -cz $tarformat -f $pkg_file ./debian-binary
./control.tar.gz ./data.tar.$cext )
+ ( cd $tmp_dir && tar -c --sort=name --mtime=$build_date $tarformat
./debian-binary ./control.tar.gz ./data.tar.$cext | gzip $compressorargs >
$pkg_file )
fi
rm $tmp_dir/debian-binary $tmp_dir/data.tar.$cext $tmp_dir/control.tar.gz
--
2.15.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto] clutter-CRITICAL **: Unable to initialize clutter: Unable to Initialize the clutter backend: no available drivers found.
On 01/29/2018 01:05 PM, kishorepasupula wrote:
>
> Hi,
>
> My main objective is to run snappy player
> (https://wiki.gnome.org/Snappy) on target machine (BeagleBone Black) so,
> I wrote a recipe for Snappy player(snappy_1.0.bb) as below
>
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=686e6cb566fd6382c9fcc7a557bf4544"
>
> SRCREV = "e73fabce4c397b40d490c74f6a6a0de000804f42"
> SRC_URI = "git://git.gnome.org/snappy"
> S = "${WORKDIR}/git"
>
> RDEPENDS_${PN} = "gtk+3 gstreamer1.0 glib-2.0 clutter-1.0
> gstreamer1.0-plugins-base libxtst clutter-gst-3.0 clutter-gtk-1.0 libx11
> cairo gdk-pixbuf"
>
> # inherit line
> inherit pkgconfig autotools
>
> FILES_${PN} += "${datadir}/*"
> Added this recipe name in local.conf
>
> IMAGE_INSTALL_append = " snappy"
> The build (bitbake core-image-sato) was successful, when I ran "snappy"
> on target(BeagleBone Black) I am getting below error response.
>
> sh-4.4# snappy
> libEGL warning: DRI2: failed to authenticate
> libEGL warning: DRI2: failed to authenticate
> libEGL warning: DRI2: failed to authenticate
>
> (snappy:763): clutter-CRITICAL **: Unable to initialize clutter: Unable
> to Initialize the clutter backend: no available drivers found.
>
> As per my Understanding in my recipe I have resolved all dependencies
> for Snappy player (such as clutter, gstreamer, gtk etc.). I'm unable to
> figure out why snappy player is throwing error? Can any one guide me on
> this?
>
> PS: Also tried adding PREFERRED_PROVIDER_virtual/egl ?= "mesa" in
> local.conf but still I'm getting the same error response.
Are you using proprietary drivers? If libegl is coming from mesa, it
will probably not work with proprietary drivers. Can you provide more
details about your setup? Which layer(s) are you using etc. and where
are the graphics recipes/drivers coming from?
Thanks,
Anuj
>
> Regards,
> Kk.
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
