[yocto] QA notification for completed autobuilder build (yocto-2.7_M3.rc1)

[pokybuild]

A build flagged for QA (yocto-2.7_M3.rc1) was completed on the autobuilder and 
is available at:


https://autobuilder.yocto.io/pub/releases/yocto-2.7_M3.rc1


Build hash information: 

bitbake: e1f252408982a62485bbf874a01fd30a02aeed32
eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316
eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718
meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
meta-intel: c7c0e12c98cec527bcdcf26594d34bbeb16057c5
meta-mingw: 750706a3501ec9f5e3fa6dcbfb13a9027b6a875e
meta-qt3: 23d7543ebd7e82ba95cbe19043ae4229bdb3b6b1
meta-qt4: b37d8b93924b314df3591b4a61e194ff3feb5517
oecore: 619a8ab875ee8e2914cd58947f342808d817833c
poky: 753e2a0ede4449917c75353b57f13bbafe70fac8



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.pur...@linuxfoundation.org


 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] linux-yocto: add bbappend for kernel 5.0

[Yi Zhao]

Signed-off-by: Yi Zhao 
---
 recipes-kernel/linux/linux-yocto_5.%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-kernel/linux/linux-yocto_5.%.bbappend

diff --git a/recipes-kernel/linux/linux-yocto_5.%.bbappend 
b/recipes-kernel/linux/linux-yocto_5.%.bbappend
new file mode 100644
index 000..7719d3b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.%.bbappend
@@ -0,0 +1 @@
+require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
'${BPN}_selinux.inc', '', d)}
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw] Windows SDK build fails using meta-qt5

[IGI - Moritz Porst]

Hello everyone,

I am trying to compile a windows sdk for my image. I use meta-mingw and 
meta-qt, the target machine is based on meta-intel (corei7-64) and the 
distribution based on poky. My build machine is an ubuntu 16.04. I have checked 
out all layers on their thud branch, except for meta-qt (master). I set 
SDK_MACHINE in local.conf to "x86_64-mingw32" "bitbake core-image-minimal -c 
populate_sdk" results on a clean rebuild (deleted sstate-cache and tmp) in (2 
errors of this kind):

""" [...] 
x86_64-nativesdk-mingw32-pokysdk-mingw32/nativesdk-qtbase/5.12.0+gitAUTOINC+13ed06640c-r0/git/qmake/library/ioutils.cpp:249:31:
 error: cannot convert 'wchar_t*' to 'LPCSTR' {aka 'const char*'}

[...] | Makefile:213: recipe for target 'ioutils.o' failed [...]
[...] ERROR: Task 
(/opt/thudPoky/meta-qt5/recipes-qt/qt5/nativesdk-qtbase_git.bb:do_configure) 
failed with exit code '1' [...] """

So I decided to remove sdk tools, hoping to be able to cross compile them 
later, by commenting out in my image:  #inherit populate_sdk_qt5

This build also failed because the build system tried to invoke "cmake 
--install" on a non-cmake directory. commenting out "inherit cmake" however 
solved the problem and the sdk was created (1.1GB .tar.gz file BUT without 
meta-qt sdk tools). I needed cmake only for a previous cross-compilation, thus 
commenting out was (at least now) no problem.
Is meta-mingw capable of compiling an sdk with meta-qt ? Could this be a bug ? 
If yes, should I rather refer to the meta-mingw maintainers or the meta-qt5 
maintainers ?
Best regards
Moritz




IGI mbH
Moritz Porst,

Langenauer Str. 46
57223 Kreuztal, Germany

[IGI Logo] 

Tel.:   +49 2732 5525 0
Fax:+49 2732 5525 25
E-mail: m.po...@igi-systems.com
Web:www.igi-systems.com
Follow us:  [IGI News Feed]  
 [IGI at YouTube]    [LinkedIn] 


Upcoming Events:
GeoBusiness 2019 London




Sitz der Gesellschaft / Company domiciled in: Kreuztal
Handelsregister / Register: Siegen HRB 1975
Ust ID Nr. / VAT Reg. No.: DE 126 580 027
Steuer Nr. / Tax No.: 342 / 5873 / 3332
Geschaeftsfuehrer / Managing Director: Christian GRIMM & Philipp GRIMM

DISCLAIMER
The information sent by means of this e-mail message is intended for the use of 
the addressee only! Publication, duplication, distribution and/or forwarding to 
third parties of this message, as well as use of the information by other 
persons than the intended recipient, is strictly prohibited. If you have 
received this communication in error, please notify the sender immediately by 
returning it.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Wic can't find mkfs.btrfs

[Timothy Froehlich]

Ok, I think I'm along the path to figuring this out. Realized that
btrfs-tools-native:do_populate_sysroot needed to be explicitly run by
something.

On Tue, Mar 19, 2019 at 12:40 PM Timothy Froehlich 
wrote:

> Been slogging through this one for a bit, would appreciate any helpful
> suggestions.
>
> I'm using mender.io's layer which includes a class that builds a full SD
> card image including multiple partitions. I'm trying to turn one of those
> partitions into a btrfs partition and my current error is "A native program
> mkfs.btrfs... was not found". Wic's source code comments suggest that it's
> looking for native utils in STAGING_DIR_NATIVE, which bitbake -e says is in
> workrecipe-sysroot, and when I checked, it
> does indeed include mkfs.ext4/vfat but not btrfs. I haven't yet found the
> mechanism that copies these files into the location (thought occurs to me
> to check the image's logs itself) so I don't know what mechanism is failing
> to copy the mkfs.btrfs but is working for mkfs.ext*. Any pointers?
>
> --
> Tim Froehlich
> Embedded Linux Engineer
> tfroehl...@archsys.io
> 215-218-8955
>


-- 
Tim Froehlich
Embedded Linux Engineer
tfroehl...@archsys.io
215-218-8955
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Wic can't find mkfs.btrfs

[Timothy Froehlich]

Been slogging through this one for a bit, would appreciate any helpful
suggestions.

I'm using mender.io's layer which includes a class that builds a full SD
card image including multiple partitions. I'm trying to turn one of those
partitions into a btrfs partition and my current error is "A native program
mkfs.btrfs... was not found". Wic's source code comments suggest that it's
looking for native utils in STAGING_DIR_NATIVE, which bitbake -e says is in
workrecipe-sysroot, and when I checked, it
does indeed include mkfs.ext4/vfat but not btrfs. I haven't yet found the
mechanism that copies these files into the location (thought occurs to me
to check the image's logs itself) so I don't know what mechanism is failing
to copy the mkfs.btrfs but is working for mkfs.ext*. Any pointers?

-- 
Tim Froehlich
Embedded Linux Engineer
tfroehl...@archsys.io
215-218-8955
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW12'19

[Scott Rifenbark]

Hi,

Here is a "start" at publicly documenting QA... I started on this a while
back and got content from Richard only.  It would be good to have eyes on
this so it could be completed.  There are holes and stuff may have
changed.  If you want, please look it over and send me feedback.

See https://yoctoproject.org/docs/scott_temp/test-manual/test-manual.html

Thanks,
Scott

On Tue, Mar 19, 2019 at 8:53 AM  wrote:

> Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)
>
> Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019
>
>
>
> SWAT Team Rotation:
>
>- SWAT lead is currently: Armin
>- SWAT team rotation: Armin -> Paul on Mar. 23, 2019
>- SWAT team rotation: Paul -> Ross on Mar. 30, 2019
>- https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>
>
> Key Status/Updates:
>
>- M3 has not built yet however most major pieces are in place,
>including now, agreement on the new QA process. The delay is partly due to
>RP travel with others able to cover being unavailable for other reasons,
>combined with infrastructure issues.
>- The remaining questions for M3 are:
>   - Public documentation of the new QA process
>   - Upgrade for uninative for glibc 2.29
>   - Mesa upgrade? (unlikely given failures in testing)
>- The Yocto Project has updated to its new governance model which
>includes establishing a Technical Steering Committee (TSC) for Yocto
>Project. This is designed to complement  and work alongside the
>OpenEmbedded TSC. Three members of the YP TSC are selected by the Yocto
>Project governing board and those people are Ross Burton, Khem Raj and
>Richard Purdie. The remaining two seats will be elected by OpenEmbedded. It
>is intended the TSC will take over the release process, SWAT team, bug
>triage and feature planning/development for 2.8.
>- YP 2.5.3 continues to be blocked on autobuilder-helper changes for
>the stable branches and the resulttool changes in master to move to the new
>QA process.
>- There is discussion on the openembedded-architecture list about
>changes to the stable branch patch criteria to bring us more into line with
>current industry best practices and thinking.
>
>
>
> Planned Releases for YP 2.7:
>
>- YP 2.7 M3 Cutoff was Feb. 25, 2019
>- YP 2.7 M3 Release Target was Mar. 8, 2019
>- YP 2.7 M4 Cutoff is Apr. 1, 2019
>- YP 2.7 M4 Release Target is Apr. 26, 2019
>
>
>
> Planned upcoming dot releases:
>
>- YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
>- YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
>- YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.
>
>
>
> Tracking Metrics:
>
>- WDD 2432 (last week 2439) (
>https://wiki.yoctoproject.org/charts/combo.html)
>- Poky Patch Metrics
>   - Total patches found: 1526 (last week 1523)
>   - Patches in the Pending State: 656 (43%) [last week 657 (43%)]
>
>
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features
>
>
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>
>
> [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 Project Manager*
>
> (*Cell*:(208) 244-4460
>
> * *Email*:  *sjolley.yp...@gmail.com
> *
>
>
> --
> ___
> 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

[yocto] Auto-clean deployed images/output files generated in a class

[Ken Sloat]

Hello,

I am writing a custom bitbake class in order to generate a custom compound 
image for my project. This class gets inherited by my normal image recipe for 
my project. I am running Sumo. In my class, I simply write a task in python and 
add the task via the normal "addtask" method.  My task runs ok, it generates 
the image I need and puts it in the deploy directory .

What I want to happen, is for the image (or any files I create in the deploy 
directory for that matter) to be deleted whenever I run the clean command for 
the image that inherits this class. I know I could probably define a 
clean_append function or something, but it seems that there is some way to set 
this up to happen automatically.

I am following this class as an example:
https://github.com/sbabic/meta-swupdate/blob/sumo/classes/swupdate.bbclass

and going through the code there, I don't really understand what statements 
cause the generated image file to be deleted, however, if I inherit that class, 
and build my image, it generates a custom image, and upon cleaning, it does 
indeed delete the generated image. If I could understand what makes this 
happen, then I would be able to do this in my image as well.

Thanks,
Ken Sloat
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW12'19

[sjolley.yp.pm]

Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)

Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Armin 
*   SWAT team rotation: Armin -> Paul on Mar. 23, 2019
*   SWAT team rotation: Paul -> Ross on Mar. 30, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Key Status/Updates:

*   M3 has not built yet however most major pieces are in place,
including now, agreement on the new QA process. The delay is partly due to
RP travel with others able to cover being unavailable for other reasons,
combined with infrastructure issues.
*   The remaining questions for M3 are:

*   Public documentation of the new QA process
*   Upgrade for uninative for glibc 2.29
*   Mesa upgrade? (unlikely given failures in testing)

*   The Yocto Project has updated to its new governance model which
includes establishing a Technical Steering Committee (TSC) for Yocto
Project. This is designed to complement  and work alongside the OpenEmbedded
TSC. Three members of the YP TSC are selected by the Yocto Project governing
board and those people are Ross Burton, Khem Raj and Richard Purdie. The
remaining two seats will be elected by OpenEmbedded. It is intended the TSC
will take over the release process, SWAT team, bug triage and feature
planning/development for 2.8.
*   YP 2.5.3 continues to be blocked on autobuilder-helper changes for
the stable branches and the resulttool changes in master to move to the new
QA process.
*   There is discussion on the openembedded-architecture list about
changes to the stable branch patch criteria to bring us more into line with
current industry best practices and thinking.

 

Planned Releases for YP 2.7:

*   YP 2.7 M3 Cutoff was Feb. 25, 2019
*   YP 2.7 M3 Release Target was Mar. 8, 2019
*   YP 2.7 M4 Cutoff is Apr. 1, 2019
*   YP 2.7 M4 Release Target is Apr. 26, 2019

 

Planned upcoming dot releases:

*   YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
*   YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
*   YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.

 

Tracking Metrics:

*   WDD 2432 (last week 2439) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1526 (last week 1523)
*   Patches in the Pending State: 656 (43%) [last week 657 (43%)]

 

Key Status Links for YP:

 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[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 Project Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Guidance to start yocto project.

[Nicolas Dechesne]

On Tue, Mar 19, 2019 at 9:24 AM Ricardo Ribalda Delgado
 wrote:
>
> With no doubt: yocto developer day.
>
> Excellent value for the money!

Just to add a bit of context here. The YP dev day are events organized
by the project, typically at ELC and ELC(E) conferences, where we have
beginners and advanced classes.

Here is a description of the last 2 events:
https://www.yoctoproject.org/learn/yocto-project-dev-day-north-america-2018/
https://www.yoctoproject.org/yocto-project-dev-day-europe-2018/

You can find slides about some of the previous sessions here:

https://www.yoctoproject.org/learn/presentation-videos/



>
> On Mon, Mar 11, 2019 at 4:47 PM Scott Rifenbark  wrote:
> >
> > H Rahul,
> >
> > I would start with the 
> > https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
> >  manual.  Gets you up and running.
> >
> > Scott
> >
> > On Mon, Mar 11, 2019 at 9:32 AM rahul chauhan  
> > wrote:
> >>
> >> Hello,
> >>
> >> I am beginner with yocto project and i want to learn the yocto project and 
> >> start working on it.
> >> can you please guide how can i proceed step by step and  what are the 
> >> prerequisites?
> >>
> >> Thanks and Regards
> >> Rahul Chauhan
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> Ricardo Ribalda
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-anaconda][PATCH] python3-anaconda: Set the same COMPATIBLE_HOST as grub

[Robert Yang]

They RDEPENDS on grub, so set the same COMPATIBLE_HOST as grub.

Signed-off-by: Robert Yang 
---
 recipes-installer/anaconda/python3-anaconda_28.22.11.bb| 3 +++
 .../packagegroups/packagegroup-anaconda-support.bb | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/recipes-installer/anaconda/python3-anaconda_28.22.11.bb 
b/recipes-installer/anaconda/python3-anaconda_28.22.11.bb
index 52eb99a..e9ae390 100755
--- a/recipes-installer/anaconda/python3-anaconda_28.22.11.bb
+++ b/recipes-installer/anaconda/python3-anaconda_28.22.11.bb
@@ -160,3 +160,6 @@ python __anonymous () {
 raise bb.parse.SkipPackage('Anaconda requires RPM packages to be the 
default in PACKAGE_CLASSES.')
 }
 
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST_armv7a = 'null'
+COMPATIBLE_HOST_armv7ve = 'null'
diff --git 
a/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb 
b/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb
index 3f3f41e..f834c52 100644
--- a/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb
+++ b/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb
@@ -27,3 +27,6 @@ RDEPENDS_${PN} = " \
 grub-efi \
 "
 
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST_armv7a = 'null'
+COMPATIBLE_HOST_armv7ve = 'null'
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Guidance to start yocto project.

[Ricardo Ribalda Delgado]

With no doubt: yocto developer day.

Excellent value for the money!

On Mon, Mar 11, 2019 at 4:47 PM Scott Rifenbark  wrote:
>
> H Rahul,
>
> I would start with the 
> https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
>  manual.  Gets you up and running.
>
> Scott
>
> On Mon, Mar 11, 2019 at 9:32 AM rahul chauhan  
> wrote:
>>
>> Hello,
>>
>> I am beginner with yocto project and i want to learn the yocto project and 
>> start working on it.
>> can you please guide how can i proceed step by step and  what are the 
>> prerequisites?
>>
>> Thanks and Regards
>> Rahul Chauhan
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Ricardo Ribalda
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to produce Release.gpg

[Ricardo Ribalda Delgado]

Hi

We do that on our build server with this script:


for a in $(find build/tmp/deploy/deb -name Release); do
 rm -f $a.gpg
 gpg -abs -o $a.gpg $a
done

Standard measures apply: signature on a yubikey that require press to
sign, but if you are less paranoid, you can just create a key with no
protection


On Mon, Mar 18, 2019 at 9:55 AM Alexander Kanavin
 wrote:
>
> On Mon, 18 Mar 2019 at 08:14, Mauro Ziliani  wrote:
> > Is it possible to sign Release automatically from bitbake?
>
> At the moment signing deb repositories is not supported (but it is
> supported for rpm and opkg).
> You are welcome to add the missing support,
> meta/lib/oe/package_manager.py is where it happens.
>
> Alex
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Ricardo Ribalda
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [psplash][PATCH 1/3] add recovered bar.png

[Stefan Agner]

Hi Ross,

On 25.02.2019 16:16, Stefan Agner wrote:
> From: Stefan Agner 
> 
> While the source files for the main splash image is present in
> the source folder base-image, the progress bar isn't. This
> patch adds the bar.png recovered from the RLE data in the bar
> header file. The tool make-image-header.sh allows to translate
> this png back the the header exactly.

I think you made the last commits to psplash. Could you consider this
patchset as well?

--
Stefan

> 
> Signed-off-by: Stefan Agner 
> ---
>  base-images/bar.png | Bin 0 -> 1849 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  create mode 100644 base-images/bar.png
> 
> diff --git a/base-images/bar.png b/base-images/bar.png
> new file mode 100644
> index
> ..e2c1f1781cdcfa68c8a664a8b3072344d3aeaf1b
> GIT binary patch
> literal 1849
> zcmV-92gdk`P)
> zaB^>EX>4U6ba`-PAZ2)IW+q+O3ysmg6W4h5xgPSpt#}g5~f$r*|;Rp9^-9
> zb;drGU@Q>2pHL__{{1!GKe#C8 zF2T1Pk8zy#1^xOMVBzeq&;8EMi8!4ToiA<^%JR%;oObD)NciZd^V#KdTnWF0bN z`?c2N)$4OGh|v}E2|FG_;_;c57r_c7OOe$sXs2bg+g{S{$)B}z_vVXuG(T(S%V{Cc
> zQaFF35MMMp`$<1*w-tJ#c5CwUi)wcl@7m3t<{U?KB}6C{-5HcWr`RnRLe3z2Sj4?1
> zRkUs28Fxa64a7QVR@}`|CWhLR0(B}hY3%Pt4ND9>*znEVSax3$ z1xo`pK{wymLfdcN{u(8C?gUFFOh%jI%k4gO{^Y(-H0MfPq9rEK(*c-QPGcF1-1>x7
> zxTnV2B6Pdm9qZ#-U zNZy!@2s$S4DOfp6;0gky%AMQ<8<7Y&*bVTFF-F^#m5*+e7JyKRVnBlp1Xv*`^2b6#
> z4iyy*PF16tCe2!+#1J*cXmQo3Vq(G6qM0SjR+6NUG{s~orJPFUEGS``V>Xvl
> zEttAsbb&=Fm8;ZHwZ>{S)m%$M`n1rr#bzzF+)C#z9oxUhZmy@Edl@v4N+S#%ao9*B
> zk1~;KQ)ZYt zFJ?Yb2)xKGW zQ0ry?qR0lccHz?0%S2)8DM#%=TFhm%94ECArAFm|P;4Odsm)B(P!>r`Z#FwhBQ`oX
> z~};_7SyN7>i?-tZ7wNpbW7f^970m(k}~RNJHo8YLkRyHw|x9S?*VV3$pV@-TS!
> zrN<$2Bv!!E?&4u)))ruZCmIf4??(=^;L^YW!g5~|++3|6ukCEP
> z!c$rUKCVwkf+4lmoS#y+@#$=pqlde7h>-btg|)-52#z!aCEPOplNj$Sd{G0Q+((${
> z>osms9-3@_?p6JH2;%=B$)U{DyXE{C!@2)fBdx_z$Gvj-S;r=AU-zJ8;!IR
> zhP%#;&%3kMrf4d;hS_nB$-_}-D0^X`j*mXNjy!dQK8~ zJZ@D3Rc=)cca)7OzN>|?$`Wg7qBxXQUUn$S9EK(7DU~G=ML(*I9Q(nyExz7$R4x3X
> zl%k|#l`b5JOc6+pOS^dA_c+r+BdtrSx}~aFQ^V-OwH0?{$8S!yiyPPvlManfe*IzO
> z4yz?*{B4)LyEm?0x`OKD`eB8)%x=`<#4o~5le{+!7EYr8u4O%v^3~{;ODi7t7Emil
> z#WV1EAuT;Zx<%x!LjP;Y=nG}$ML^GS!^pjBa}~~W%&)B7^c0Yst9<}=!
> z?044gXRu!*x9oVPkrGZ0inB^*NQeU(%`tGWsTcmWPv7y+`9K}CS~8Ac-Kocz5n3jc
> z6K#1+lz`4PmIfJcjKRO2?my>cBAz3|;LZR5010qNS#tmYE+YT{E+YYWr9XB6000Mc
> zNliru;{p;D2os84rL_P60n$lCK~#9!?cG638$lSx@n?7TQoMw<*=PwKJ>*!Sq)`y_
> zEriljK=1OAfhJLN%MX zGu~wKeXgI9WTIa0tFEqoC{3rD&!4sc{9~TyDGUqR*m$FA^{t}l^{>6hVxFJJIz9cO
> zEXzm?$eHi^+S_}tot<}!wIp@B7izUSloEI$S(d5Q>ZsejSQIl)sx5Bm*pgcDtiA
> zohpdqOId53&9$|n4h}w$67bB9k3Z|?X8g3a)+ ztIljVyp}&2jh$hovMFN>i2*q<#;8)+bY`Q`SpID0zQ(Ssydo_iN4vXKXFZ$Q#jmme
> zmJ7uMC?)`k2~bP`6ceDB04OFvF#%9a02C9Tm;fjy@ZT0Q2;9GT-QC@j3Xr3-v!1gK
> z0wcdvDmue{fAGhN1^}LiwO0N9z?qdwMfv6Ox-(3YTQ!>}BnIT5**sB_+
> z@NIr{^oge=ump@TIz0R+KMV`1*SARoSOWF>w!*NWK$2>;EoGVIz-QovJRbO5t8Gd8
> n?IiZa_e-uw0P^y;D-s?6yTzgg!=Gv;0NkvXXu0mjfd-8h+
> 
> literal 0
> HcmV?d1
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto][meta-qt5][qtwayland]Qtwayland recipe fails with Yocto 2.5

[Priyanshu Sharma]

Hi All,

I'm consistently getting a build failure after upgrading Poky to 2.5 from
2.2 on qtwayland
Yocto recipe from meta-qt5.

The error looks like :

| Running configuration tests...
| Checking for Wayland client library... yes
| Checking for Wayland cursor library... yes
| Checking for wayland-scanner... yes
| Checking for Wayland EGL library... yes
| Checking for wayland-server... yes
| Done running configuration tests.
|
| Configure summary:
|
| Qt Wayland Drivers:
|   EGL  no
|   Raspberry Pi ... no
|   XComposite EGL . no
|   XComposite GLX . no
|   DRM EGL  no
|   libhybris EGL .. no
| Qt Wayland Client  yes
| Qt Wayland Compositor  yes
|
| ERROR: Feature 'wayland-egl' was enabled, but the pre-condition
'features.wayland-client && features.opengl && features.egl &&
libs.wayland-egl' failed.
|
| ERROR: Feature 'wayland-egl' was enabled, but the pre-condition
'features.wayland-server && features.opengl && features.egl &&
libs.wayland-egl' failed.
|
| Check config.log for details.
| WARNING: exit code 1 from a shell command.
I've checked that only pre-condition "features.egl" is failing.
I've my own custom recipe which is providing virtual/egl and is set as
PREFERRED_PROVIDER also.
What is the missing dependency here when virtual/egl is provided?
What exactly is features.egl looking for? ( virtual/egl provides egl.pc )
I've not changed anything in meta-qt5 layer. And the version is 5.9.2
QT5. However, is fails with 5.12 also.


Warm Regards,

Priyanshu Sharma
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto