[yocto] QA notification for completed autobuilder build (yocto-2.5.3.rc3)
A build flagged for QA (yocto-2.5.3.rc3) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-2.5.3.rc3 Build hash information: bitbake: c0af6c81f8d5487ea2cef54a78fd1cb1d0dc6520 eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316 eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718 meta-gplv2: d7687d404bbc9ba3f44ec43ea8828d9071033513 meta-intel: ba5f7ecd26630b74b6338c1828847a64ab172453 meta-mingw: 628dcfed62ce8dcc408e5b4a5e5c0aaa921b20ad meta-qt3: 02f273cba6c25f5cf20cb66d8a417a83772c3179 meta-qt4: 8e791c40140460825956430ba86b6266fdec0a93 oecore: 0a2db923fd17019d07d88204b355aa46590f0b97 poky: 84b78df15ff77b2fe2aeb62fcaa265dce7ebfbbb 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
Re: [yocto] SDK build fails at latest thud
On Mon, Mar 18, 2019 at 7:21 AM Teemu K wrote: > > On Fri, Mar 15, 2019 at 2:17 AM akuster wrote: > > > > > > > > On 3/13/19 9:50 PM, Teemu K wrote: > > > > Hi, > > > > I noticed that when trying to build sdk on thud it fails on latest > > version. Actually it broke somewhere between commits: > > > > 1cab405d88149fd63322a867c6adb4a80ba68db3 (old) > > 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new) > > > > I'm using it with meta-freescale - layer to build image to iMX8. > > > > I'm using command 'populate_sdk' and it works fine on older version, > > but newer version it fails with error: > > > > Can you provide the steps to reproduce? > bitbake my-image-name -c populate_sdk > > > > > == > > The following packages have unmet dependencies: > > target-sdk-provides-dummy : Conflicts: coreutils > > E: Unable to correct problems, you have held broken packages. > > > > > > There is a change sitting in stable/thud-next: > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next=af5cf78b275ab5226354337d25d8dc1c41a08904 > > > > which might be related. Can you try that branch? > > > > git://git.yoctoproject.org/poky-contrib stable/thud-next > That did not solve the problem. I have coreutils in my image and it > kept conflicting. When I removed coreutils from my image it solved > that problem, but there were some problems with perl etc. From the > working version all those are missing from > target-sdk-provices-dummy.bb and my original image works just fine. I see that thud-branch has gotten even more 'fixes' for this sdk thing in last week, but the actual problem still stays. If image-recipe uses coreutils - recipe sdk build fails there because target-sdk-provides-dummy.bb has it listed. And if I remove that then it fails on next package.In my case it's bash-dev. Does those changes need something different how sdk is build or how to build sdk with those changes? I'm not sure why they are listed there in the first place if it overrides the actual package and does not provide 'dummy' if/when needed. To create sdk I use this command: bitbake -c populate_sdk -Teemu -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)
A build flagged for QA (yocto-2.6.2.rc3) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc3 Build hash information: bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316 eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718 meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575 meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5 meta-qt3: 23d7543ebd7e82ba95cbe19043ae4229bdb3b6b1 meta-qt4: b37d8b93924b314df3591b4a61e194ff3feb5517 oecore: 45032e30be70503faeee468159b216031b729309 poky: faeb366bc3eb322f5f203cfe08dc4cf529a822e9 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
Re: [yocto] [PATCH 1/1] libselinux.inc: Add python-shell to libselinux-python RDEPENDS.
Thanks Chris, I will merge this soon as I just tripped over it yesterday. Good
timing.
Please try to remember to flag stuff for meta-selinux with that in the subject,
though, so it gets caught by correct filters on our end.
Thanks,
-J.
On Mar 27, 2019 15:53, Chris PeBenito
wrote:
The libselinux SWIG wrapper imports shutil.
Signed-off-by: Chris PeBenito
---
recipes-security/selinux/libselinux.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/selinux/libselinux.inc
b/recipes-security/selinux/libselinux.inc
index 33621cc..6e115e3 100644
--- a/recipes-security/selinux/libselinux.inc
+++ b/recipes-security/selinux/libselinux.inc
@@ -9,7 +9,7 @@ inherit lib_package pythonnative
DEPENDS += "libsepol python libpcre swig-native"
DEPENDS_append_libc-musl = " fts"
-RDEPENDS_${PN}-python += "python-core"
+RDEPENDS_${PN}-python += "python-core python-shell"
PACKAGES += "${PN}-python"
FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}/site-packages/*"
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] ref-manual: Mention that staging class is enabled by default.
This information is present for all other classes inherited by base class. Previously it was mentioned for staging class to but then it was gonne. Signed-off-by: Vasyl Vavrychuk --- documentation/ref-manual/ref-classes.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml index 22659821bc..8f301e81ae 100644 --- a/documentation/ref-manual/ref-classes.xml +++ b/documentation/ref-manual/ref-classes.xml @@ -3376,6 +3376,11 @@ This check was removed for YP 2.3 release + + +This class is enabled by default since it is inherited by +the base class. + -- 2.20.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] ref-manual: Fix mistake in base class description.
Clearly, previous sentense speaks about definitions in classes which can be overrided or extended in other classes. Signed-off-by: Vasyl Vavrychuk --- documentation/ref-manual/ref-classes.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml index d602851c54..22659821bc 100644 --- a/documentation/ref-manual/ref-classes.xml +++ b/documentation/ref-manual/ref-classes.xml @@ -190,7 +190,7 @@ tasks such as fetching, unpacking, configuring (empty by default), compiling (runs any Makefile present), installing (empty by default) and packaging (empty by default). -These classes are often overridden or extended by other classes +These definitions are often overridden or extended by other classes such as the autotools class or the -- 2.20.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] build SYSLINUX module
Hallo, We have changed your system from yocto 1.6.2 to V2.5.2. On old system we use syslinux 4.07 with a own module. Now I see, that all modules in syslinux are compile, and the syslinux.bb create only new installer files. But how can i compile our own module ? It's in a subfolder of com32/our_own/*.c + Makefile Thanks Johann -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] v4.18.x - stable updates comprising v4.18.33
Bruce, Yocto kernel folks: Here is the next 4.18.x stable update "extension" primarily created for the Yocto project, continuing from the previous v4.18.32 release. There are about 260 commits here, based on commits chosen from what was used in the recent 4.19.31 stable release. So, yes, another bigger one, but still no one big feature/area was responsible. I've put this 4.18.x queue through the usual testing; build testing on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis and finally some sanity runtime tests on x86-64. I did the signed tag just as per the previously released versions. Please find a signed v4.18.33 tag using this key: http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6 in the repo in the kernel.org directory here: https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/ git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git for merge to standard/base in linux-yocto-4.18 and then out from there into the other base and BSP branches. For those who are interested, the evolution of the commits is here: https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/ This repo isn't needed for anything; it just exists for transparency and so people can see the evolution of the raw commits that were originally selected to create this 4.18.x release. Paul. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [Yocto][meta-qt5][qtwayland]Qtwayland recipe fails with Yocto 2.5
Found that the missing features.egl is provided by QTBase recipe. And in my case, qtbase is not compiling the feature "EGL" and thats why qtwayland fails to find it. egl is not included in PACKAGECONFIG of qtbase recipe. However, it used to be enabled with Yocto 2.2. Adding it PACKAGECONFIG[eg] of qtbase is not enabling it. How can egl be enabled in qtbase? Warm regards, Priyanshu Sharma On Tue, Mar 19, 2019 at 1:23 PM Priyanshu Sharma < ms.priyanshu.sha...@gmail.com> wrote: > 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
Re: [yocto] [meta-security][PATCH 2/2] sssd: fix libcrypto version used
On Tue, Mar 26, 2019 at 03:52:39PM -0700, akuster808 wrote: > > > On 3/26/19 3:24 AM, Adrian Bunk wrote: > > On Mon, Mar 25, 2019 at 09:58:55AM -0700, Armin Kuster wrote: > >> Signed-off-by: Armin Kuster > >> --- > >> recipes-security/sssd/sssd_1.16.3.bb | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/recipes-security/sssd/sssd_1.16.3.bb > >> b/recipes-security/sssd/sssd_1.16.3.bb > >> index 8f7f805..d39fa23 100644 > >> --- a/recipes-security/sssd/sssd_1.16.3.bb > >> +++ b/recipes-security/sssd/sssd_1.16.3.bb > >> @@ -33,7 +33,7 @@ PACKAGECONFIG[manpages] = "--with-manpages, > >> --with-manpages=no" > >> PACKAGECONFIG[python2] = "--with-python2-bindings, > >> --without-python2-bindings" > >> PACKAGECONFIG[python3] = "--with-python3-bindings, > >> --without-python3-bindings" > >> PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss," > >> -PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto" > >> +PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto10" > >> ... > > This looks wrong for multiple reasons, and it still gave the same error > > when I tried it. > That is troubling. I don't see any errors here. Thanks for the feed > back. I will have to dig at this a bit more. > > Can you provide some build detail so that I can reproduce it? Try building the package without nss but with cyrpto (sic) in PACKAGECONFIG. > > How has this change been tested? > Not for this change. > > Which reminds me I should automate some testing for this package. This is not about automating testing. This is about first reproducing the problem you are trying to fix, and then verifying that your fix actually fixes this problem. Which is the fundamental way to do any kind of bugfixing.[1] This one line already contained two bugs,[2] and the commit added a third problem (usage of OpenSSL 1.0) without fixing any of these bugs. The commit message not stating any reason why this change was done only adds to the confusion. I thought originally this was a workaround for code not building with OpenSSL 1.1, which would then also be required for thud. > regards, > Armin cu Adrian [1] this is not one of the harder cases where reproducing the problem would be a problem [2] "cyrpto", and "libcrypto" instead of "openssl p11-kit" -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
