Re: [yocto] [meta-selinux][PATCH 1/3] libselinux: refresh patches to fix QA warning
Hi Martin, 在 2018年04月16日 14:07, Martin Hundebøll 写道: Hi Yi, On 2018-04-13 10:38, Yi Zhao wrote: Refresh patches with devtool command to fix do_patch warning. Signed-off-by: Yi Zhao--- ...c-Makefile-fix-includedir-in-libselinux.pc.patch | 14 ++ .../libselinux-define-FD_CLOEXEC-as-necessary.patch | 14 ++ ...ibselinux-drop-Wno-unused-but-set-variable.patch | 21 +++-- .../libselinux-make-O_CLOEXEC-optional.patch | 12 +--- .../libselinux-make-SOCK_CLOEXEC-optional.patch | 14 ++ 5 files changed, 38 insertions(+), 37 deletions(-) diff --git a/recipes-security/selinux/libselinux/0001-src-Makefile-fix-includedir-in-libselinux.pc.patch b/recipes-security/selinux/libselinux/0001-src-Makefile-fix-includedir-in-libselinux.pc.patch index 72b97df..c1d2b13 100644 --- a/recipes-security/selinux/libselinux/0001-src-Makefile-fix-includedir-in-libselinux.pc.patch +++ b/recipes-security/selinux/libselinux/0001-src-Makefile-fix-includedir-in-libselinux.pc.patch @@ -1,4 +1,4 @@ -From 63d2c02a4dfa5ccd5d62a9f80b6a50cbb9946fbb Mon Sep 17 00:00:00 2001 +From c5bec43d3fae49e36997884448fc533462028b67 Mon Sep 17 00:00:00 2001 From: Robert Yang Date: Thu, 18 Feb 2016 02:39:16 + Subject: [PATCH] src/Makefile: fix includedir in libselinux.pc @@ -6,23 +6,21 @@ Subject: [PATCH] src/Makefile: fix includedir in libselinux.pc Upstream-Status: Pending Signed-off-by: Robert Yang + --- src/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile b/src/Makefile -index 1920029..06d291d 100644 +index a89c0f7..f304032 100644 --- a/src/Makefile +++ b/src/Makefile -@@ -115,7 +115,7 @@ $(LIBSO): $(LOBJS) - ln -sf $@ $(TARGET) +@@ -148,7 +148,7 @@ $(LIBSO): $(LOBJS) + ln -sf $@ $(TARGET) $(LIBPC): $(LIBPC).in ../VERSION - sed -e 's/@VERSION@/$(VERSION)/; s:@prefix@:$(PREFIX):; s:@libdir@:$(LIBBASE):; s:@includedir@:$(INCLUDEDIR):' < $< > $@ + sed -e 's/@VERSION@/$(VERSION)/; s:@prefix@:$(PREFIX):; s:@libdir@:$(LIBBASE):; s:@includedir@:${prefix}/include:' < $< > $@ selinuxswig_python_exception.i: ../include/selinux/selinux.h - bash exception.sh > $@ --- -2.5.0 - + bash -e exception.sh > $@ || (rm -f $@ ; false) diff --git a/recipes-security/selinux/libselinux/libselinux-define-FD_CLOEXEC-as-necessary.patch b/recipes-security/selinux/libselinux/libselinux-define-FD_CLOEXEC-as-necessary.patch index 1fa1fba..d2a362e 100644 --- a/recipes-security/selinux/libselinux/libselinux-define-FD_CLOEXEC-as-necessary.patch +++ b/recipes-security/selinux/libselinux/libselinux-define-FD_CLOEXEC-as-necessary.patch @@ -1,7 +1,7 @@ -From 9a843a025fb0eaad537eb9dce28da539cf2cb9c2 Mon Sep 17 00:00:00 2001 +From 967beb17658f3f879a2b8640e40c0675e814a257 Mon Sep 17 00:00:00 2001 From: Joe MacDonald Date: Tue, 15 Oct 2013 10:14:41 -0400 -Subject: [PATCH 2/3] libselinux: define FD_CLOEXEC as necessary +Subject: [PATCH] libselinux: define FD_CLOEXEC as necessary In truly old systems, even FD_CLOEXEC may not be defined. Produce a warning and duplicate the #define for FD_CLOEXEC found in @@ -10,15 +10,16 @@ asm-generic/fcntl.h on more modern platforms. Uptream-Status: Inappropriate Signed-off-by: Joe MacDonald + --- - libselinux/src/setrans_client.c | 5 + + src/setrans_client.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/setrans_client.c b/src/setrans_client.c -index f9065bd..e07a779 100644 +index fa188a8..a94f02c 100644 --- a/src/setrans_client.c +++ b/src/setrans_client.c -@@ -38,6 +38,11 @@ static pthread_key_t destructor_key; +@@ -39,6 +39,11 @@ static pthread_key_t destructor_key; static int destructor_key_initialized = 0; static __thread char destructor_initialized; @@ -30,6 +31,3 @@ index f9065bd..e07a779 100644 /* * setransd_open * --- -1.7.10.4 - The above patch looks pretty much like a no-op? Sorry that I missed your mail a long time. I used devtool finish --force-patch-refresh to refresh the patches. This command would adjust all patches for the recipe. Although some of patches don't cause the QA warning, the devtool command also refresh them follow its rules. This is harmless and make all patches have uniform format. Regards, Yi diff --git a/recipes-security/selinux/libselinux/libselinux-drop-Wno-unused-but-set-variable.patch b/recipes-security/selinux/libselinux/libselinux-drop-Wno-unused-but-set-variable.patch index 9deb67d..20c0c69 100644 --- a/recipes-security/selinux/libselinux/libselinux-drop-Wno-unused-but-set-variable.patch +++ b/recipes-security/selinux/libselinux/libselinux-drop-Wno-unused-but-set-variable.patch @@ -1,17 +1,26 @@ -Subject: libselinux: drop flag: -Wno-unused-but-set-variable +From
Re: [yocto] Yocto Project changes in progress
Once I (at least I can speak for myself) embarked on this YOCTO ship, voluntarily, I do not consider leaving it. I like the concept, although there are problems with it. I could not commit too much time to it (since I have another commitments), but I keep one eye on it, primarily trying to learn, and, as abilities allow, to help. Big IT players' politics is driven primarily by interest. And interest is changing over Time, due to Global Policies and Economy shifting... Well! Zoran ___ On Tue, May 8, 2018 at 11:20 PM, Jeff Osier-Mixonwrote: > Many projects function this way. It is one of the strengths of the open > source process. > > I'd be happy to answer any questions. > > > On Mon, May 7, 2018 at 9:53 PM, Zoran Stojsavljevic > wrote: >> >> Very interesting, indeed! Newer knew that Richard (Purdie) is/was >> INTEL employee!? >> >> This announcement gives several (conspiracy?) theories... Some >> official, some unofficial. ;-) >> >> As independent thinker... IMHO. >> >> Time Will Tell! >> >> Zoran Stojsavljevic >> ___ >> >> On Mon, May 7, 2018 at 11:53 PM, Jeff Osier-Mixon wrote: >> > Hello everyone. I'd like to briefly address rumors around Richard >> > Purdie's >> > transition from Intel to a more neutral position, and Intel's reduction >> > in >> > resources for the project. >> > >> > We set up the Yocto Project in 2010 through Linux Foundation, with over >> > 20 >> > member organizations, so it would function as a true open source project >> > - >> > neutral, unbiased, and well distributed. Those things are what make open >> > source projects less vulnerable to any one person or company. This is >> > actually a very exciting transitional time for the project, and all >> > existing >> > member organizations are fully behind the project. We will let people >> > know >> > details as they are available. >> > >> > Meanwhile, the 2.5 "Sumo" release is on the way and should be released >> > soon, >> > the 2.6 planning process has started in earnest (please participate!), >> > and >> > we are excited to see what the future has in store for the project. >> > >> > -- >> > Jeffrey “Jefro” Osier-Mixon, Intel Corporation >> > Open Source Community Ecosystem Strategist >> > >> > >> > -- >> > ___ >> > yocto mailing list >> > yocto@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/yocto >> > > > > > > -- > Jeffrey “Jefro” Osier-Mixon, Intel Corporation > Open Source Community Ecosystem Strategist > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project changes in progress
Many projects function this way. It is one of the strengths of the open source process. I'd be happy to answer any questions. On Mon, May 7, 2018 at 9:53 PM, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > Very interesting, indeed! Newer knew that Richard (Purdie) is/was > INTEL employee!? > > This announcement gives several (conspiracy?) theories... Some > official, some unofficial. ;-) > > As independent thinker... IMHO. > > Time Will Tell! > > Zoran Stojsavljevic > ___ > > On Mon, May 7, 2018 at 11:53 PM, Jeff Osier-Mixonwrote: > > Hello everyone. I'd like to briefly address rumors around Richard > Purdie's > > transition from Intel to a more neutral position, and Intel's reduction > in > > resources for the project. > > > > We set up the Yocto Project in 2010 through Linux Foundation, with over > 20 > > member organizations, so it would function as a true open source project > - > > neutral, unbiased, and well distributed. Those things are what make open > > source projects less vulnerable to any one person or company. This is > > actually a very exciting transitional time for the project, and all > existing > > member organizations are fully behind the project. We will let people > know > > details as they are available. > > > > Meanwhile, the 2.5 "Sumo" release is on the way and should be released > soon, > > the 2.6 planning process has started in earnest (please participate!), > and > > we are excited to see what the future has in store for the project. > > > > -- > > Jeffrey “Jefro” Osier-Mixon, Intel Corporation > > Open Source Community Ecosystem Strategist > > > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > -- Jeffrey “Jefro” Osier-Mixon, Intel Corporation Open Source Community Ecosystem Strategist -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to create a build for ARM Cortex-A8, S5PV210
Hi. I'm new to yocto. So I have followed a tutorial and now I have crewated my first yocto distro for i386. Now I need to create a build for my device. It is a Samsung S5PV210 device, Cortex A8. Here there is a description http://www.friendlyarm.net/products/mini210 Can someone suggest me how to setup the yocto build for this target? Regards. +39.347.4070897 www.labcsp.com[1] www.denisgottardello.it[2] GMT+1 Skype: mrdebug [1] http://www.labcsp.com [2] http://www.denisgottardello.it -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Native curl and SSL CA certificates
On 05/08/2018 05:55 PM, Iván Castell wrote: Is this a bug related with curl or ca-certificates recipe? What should be the right way to fix it? Fetching and installing packages over the network during image creation is not supported or tested in YP. You need to build them locally, with recipes. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QT5.8 -qtwebengine SDK generation fails
there isnt enough information in the logs that can be built upon to help you. you might want to enable some verbosity with smart and try to find out why it fails. secondly, try the same with newer releases and see if the problem is reproducible. On Sun, May 6, 2018 at 11:18 PM, Chinthamol CS.wrote: > Hi, > > We are using a i.MX8 board and we need to develop QT application based on > qtwebengine. QT version used here is 5.8. > > We are using QT Creator with an external tool chain. we have to populate the > SDK out of our yocto image. > > When we start to include qtwebengine to the > packagegroup-qt5-toolchain-target.bb, we are getting errors. This step is > required as otherwise the qtwebengine binary will be missing in the SDK and > QT Creator will complain about that. > > We are using the imx-morty branch with Kernel Version as 4.9.51of the i.MX > yocto BSP. > > The problem can be triggered with either "bitbake -c populate_sdk > image-name" or with "bitbake meta-toolchain-qt5". > > Error log is attached with this email. We really cannot find the reason why. > > Any tips for how to proceed? > > Below mentioned link says, Use webkit instead of webengine. > > https://community.nxp.com/thread/473203# > > Anyway we have to use qtwebengine for web browsing, not qtwebkit.. Please > provide one solution to resolve this issue. > > Any help from anyone is greatly appreciated. > > > > Thanks, > > Chintha > > > > > > > > Confidentiality Statement / Disclaimer : This message and any attachments is > intended for the sole use of the intended recipient. It may contain > confidential information. Any unauthorized use, dissemination or > modification is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately then delete it from all your systems, > and do not copy, use or print. Internet communications are not secure and it > is the responsibility of the recipient to make sure that it is > virus/malicious code exempt. > > The company/sender cannot be responsible for any unauthorized alterations or > modifications made to the contents. If you require any form of confirmation > of the contents, please contact the company/sender. The company/sender is > not liable for any errors or omissions in the content of this message. > > > > -- > ___ > 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] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core
[Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core] On 18.05.07 (Mon 10:20) akuster808 wrote: > > > On 04/14/2018 07:08 PM, Armin Kuster wrote: > > Missing or unbuildable dependency chain was: ['meta-world-pkgdata', > > 'restorecond', 'libselinux', 'python-importlib'] > > > > Signed-off-by: Armin Kuster> ping Hey all, I'm working through selinux issues now. -J. > > --- > > 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 bd5ce8d..51d0875 100644 > > --- a/recipes-security/selinux/libselinux.inc > > +++ b/recipes-security/selinux/libselinux.inc > > @@ -8,7 +8,7 @@ LICENSE = "PD" > > inherit lib_package pythonnative > > > > DEPENDS += "libsepol python libpcre swig-native" > > -RDEPENDS_${PN}-python += "python-importlib" > > +RDEPENDS_${PN}-python += "python-core" > > > > PACKAGES += "${PN}-python" > > FILES_${PN}-python = > > "${libdir}/python${PYTHON_BASEVERSION}/site-packages/*" > -- -Joe MacDonald. :wq signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Autogenerate python dependencies after do_fetch
Hi, I just want to see if someone has encountered this problem before. I have a Yocto repository with a custom layer that has a recipe for my custom python app (which is in its own repository). The python app has all the requirements defined in setup.py and those have been manually added to the recipe. The problem arises when the python app gets a dependency update. For example: Starting state: App dependency in setup.py -> soco 0.12 Dependency version in Yocto -> 0.12 Intermediate step [runtime broken]: App dependency in setup.py -> soco 0.12 Dependency version in Yocto -> 0.14 Final step [runtime fixed again]: App dependency in setup.py -> soco 0.14 Dependency version in Yocto -> 0.14 Feels like an unfortunate cyclic dependency. One of the methods that come to mind is to have automatic generation of dependencies in the recipe after do_fetch has happened... Perhaps someone has a better idea :) ? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Native curl and SSL CA certificates
Hello forum. Using the "rocko" branch. The SSL CA certificates "ca-certificates.crt" don't appear inside this directory: build/tmp/work/x86_64-linux/curl-native/7.54.1-r0/recipe-sysroot-native/etc/ssl/certs/ That generates issues when trying to build images that use a https repository of rpm packages: This is the repository configuration included: $ yocto-adv-rpm.repo [yocto-adv-rpm] name=Rocko Yocto Repo baseurl=https://storage.googleapis.com/my_repo/ gpgkey=https://storage.googleapis.com/my_repo/PACKAGEFEED-GPG-KEY-rocko enabled=1 gpgcheck=1 This repository configuration doesn't work fine. When I try to build "myimage" recipe, I always get this error: ERROR: myimage-1.0-r0 do_rootfs: [log_check] myimage: found 1 error message in the logfile: [log_check] Failed to synchronize cache for repo 'yocto-adv-rpm', disabling. ERROR: myimage-1.0-r0 do_rootfs: Function failed: do_rootfs ERROR: Logfile of failure stored in: /home/yocto/yocto/build/tmp/work/machine-poky-linux/myimage/1.0-r0/temp/log.do_rootfs.731 ERROR: Task (/home/yocto/yocto/sources/meta-mylayer/recipes-images/myimage.bb:do_root I found some relevant information inside this file: yocto/build/tmp/work/machine-poky-linux/myimage/1.0-r0/temp/dnf.librepo.log The relevant part: 15:56:41 lr_download: Downloading started 15:56:41 check_transfer_statuses: Transfer finished: repodata/repomd.xml (Effective url: https://storage.googleapis.com/my_repo/repodata/repomd.xml) 15:56:41 check_finished_transfer_status: Fatal error - Curl code (77): Problem with the SSL CA cert (path? access rights?) for https://storage.googleapis.com/my_repo/repodata/repomd.xml [error setting certificate verify locations: CAfile: /home/yocto/yocto/build/tmp/work/x86_64-linux/curl-native/7.54.1-r0/recipe-sysroot-native/etc/ssl/certs/ca-certificates.crt CApath: none] 15:56:41 lr_yum_download_repomd: repomd.xml download was unsuccessful This can be fixed copying "ca-certificates.crt" inside the provided directory (manually): $ cp /etc/ssl/certs/ca-certificates.crt /home/yocto/yocto/build/tmp/work/x86_64-linux/curl-native/7.54.1-r0/recipe-sysroot-native/etc/ssl/certs/ I assume "ca-certificates.crt" file should be already included in that path. Is this a bug related with curl or ca-certificates recipe? What should be the right way to fix it? Thank you in advance. Kind regards, -- Ivan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [4.12][PATCH] ACPI / watchdog: Fix off-by-one error at resource assignment
merged. Bruce On 05/08/2018 05:30 AM, Liwei Song wrote: From: Takashi Iwaicommit b1abf6fc49829d89660c961fafe3f90f3d843c55 upstream. The resource allocation in WDAT watchdog has off-one-by error, it sets one byte more than the actual end address. This may eventually lead to unexpected resource conflicts. Fixes: 058dfc767008 (ACPI / watchdog: Add support for WDAT hardware watchdog) Cc: 4.9+ # 4.9+ Signed-off-by: Takashi Iwai Acked-by: Mika Westerberg Acked-by: Guenter Roeck Signed-off-by: Rafael J. Wysocki Signed-off-by: Liwei Song --- drivers/acpi/acpi_watchdog.c | 4 ++-- drivers/watchdog/wdat_wdt.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/acpi_watchdog.c b/drivers/acpi/acpi_watchdog.c index 8c4e0a18460a..87648aa645ba 100644 --- a/drivers/acpi/acpi_watchdog.c +++ b/drivers/acpi/acpi_watchdog.c @@ -74,10 +74,10 @@ void __init acpi_watchdog_init(void) res.start = gas->address; if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { res.flags = IORESOURCE_MEM; - res.end = res.start + ALIGN(gas->access_width, 4); + res.end = res.start + ALIGN(gas->access_width, 4) - 1; } else if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { res.flags = IORESOURCE_IO; - res.end = res.start + gas->access_width; + res.end = res.start + gas->access_width - 1; } else { pr_warn("Unsupported address space: %u\n", gas->space_id); diff --git a/drivers/watchdog/wdat_wdt.c b/drivers/watchdog/wdat_wdt.c index 6d1fbda0f461..0da9943d405f 100644 --- a/drivers/watchdog/wdat_wdt.c +++ b/drivers/watchdog/wdat_wdt.c @@ -392,7 +392,7 @@ static int wdat_wdt_probe(struct platform_device *pdev) memset(, 0, sizeof(r)); r.start = gas->address; - r.end = r.start + gas->access_width; + r.end = r.start + gas->access_width - 1; if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { r.flags = IORESOURCE_MEM; } else if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] v4.12.x - stable updates comprising v4.12.23
On 04/30/2018 04:22 PM, Paul Gortmaker wrote: Bruce, Yocto kernel folks: Here is another 4.12.x stable update "extension" primarily created for the Yocto project, continuing on top of the previous v4.12.22 kernel. There about 150 commits here, with no real multi-commit topics, meaning things are returning to what is normal for a stable release. It is just a few CVEs that I was made aware of, plus selected content based on what was used for 4.14-stable that would also be appropriate for the 4.12 kernel here. As usual, I've put this 4.12.x queue through the various testing that I figured made sense, which includes but is not limited to: -x86-64 sanity boot test + workloads of defconfig on COTS Core2 box. -build MIPS, PPC, ARM, ARM64 with defconfig -build x86-64 allmodconfig/allyesconfig -build i386 allmodconfig/allyesconfig I bumped the 4.12 Makefile and did the signed tag just as per the previously released 4.12.x versions. Thanks Paul. These are now merged. Bruce Please find a signed v4.12.23 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.12.y.git/ git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git for merge to standard/base in linux-yocto-4.12 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.12.git/ This repo isn't needed for anything; it just exists for transparency and so people can see the raw commits that were used to create this 4.12.x release, similar to Greg's stable queue: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/ Paul. -- -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] ROOTFS_RPM_DEBUG undocumented
On 05/08/2018 12:33 PM, Peter Kjellerstedt wrote: FYI, the already applied patch only solves half the problem. I have an updated version that solves all of it that I am preparing for publication. I only need to make some verifications first... I just found that out as well. Lua is not relevant, we don't even enable or build it. Anyway, I've been fighting*scratch*convincing upstream all morning that fcntl bombs are a real problem under Docker, you are welcome to join :) https://bugzilla.redhat.com/show_bug.cgi?id=1537564 Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QT5.8 -qtwebengine SDK generation fails
> The problem can be triggered with either "bitbake -c populate_sdk image-name" > or with "bitbake meta-toolchain-qt5". Maybe this can help... Hope dies last! ;-) http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard Zoran ___ On Mon, May 7, 2018 at 8:18 AM, Chinthamol CS.wrote: > Hi, > > We are using a i.MX8 board and we need to develop QT application based on > qtwebengine. QT version used here is 5.8. > > We are using QT Creator with an external tool chain. we have to populate the > SDK out of our yocto image. > > When we start to include qtwebengine to the > packagegroup-qt5-toolchain-target.bb, we are getting errors. This step is > required as otherwise the qtwebengine binary will be missing in the SDK and > QT Creator will complain about that. > > We are using the imx-morty branch with Kernel Version as 4.9.51of the i.MX > yocto BSP. > > The problem can be triggered with either "bitbake -c populate_sdk > image-name" or with "bitbake meta-toolchain-qt5". > > Error log is attached with this email. We really cannot find the reason why. > > Any tips for how to proceed? > > Below mentioned link says, Use webkit instead of webengine. > > https://community.nxp.com/thread/473203# > > Anyway we have to use qtwebengine for web browsing, not qtwebkit.. Please > provide one solution to resolve this issue. > > Any help from anyone is greatly appreciated. > > > > Thanks, > > Chintha > > > > > > > > Confidentiality Statement / Disclaimer : This message and any attachments is > intended for the sole use of the intended recipient. It may contain > confidential information. Any unauthorized use, dissemination or > modification is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately then delete it from all your systems, > and do not copy, use or print. Internet communications are not secure and it > is the responsibility of the recipient to make sure that it is > virus/malicious code exempt. > > The company/sender cannot be responsible for any unauthorized alterations or > modifications made to the contents. If you require any form of confirmation > of the contents, please contact the company/sender. The company/sender is > not liable for any errors or omissions in the content of this message. > > > > -- > ___ > 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] ROOTFS_RPM_DEBUG undocumented
> -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Alexander Kanavin > Sent: den 7 maj 2018 12:12 > To: Mirza Krak> Cc: Yocto list discussion > Subject: Re: [yocto] ROOTFS_RPM_DEBUG undocumented > > On 05/07/2018 12:03 PM, Mirza Krak wrote: > > I have also been bitten by rpm performance issues in docker and glad > > that I found this. I am in the process of verifying above (on pyro > > branch). > > > > Is this patch on its way to pyro and rocko branches? > > As far as I know, no. You are welcome to backport and submit. > > Alex FYI, the already applied patch only solves half the problem. I have an updated version that solves all of it that I am preparing for publication. I only need to make some verifications first... //Peter -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [4.12][PATCH] ACPI / watchdog: Fix off-by-one error at resource assignment
From: Takashi Iwaicommit b1abf6fc49829d89660c961fafe3f90f3d843c55 upstream. The resource allocation in WDAT watchdog has off-one-by error, it sets one byte more than the actual end address. This may eventually lead to unexpected resource conflicts. Fixes: 058dfc767008 (ACPI / watchdog: Add support for WDAT hardware watchdog) Cc: 4.9+ # 4.9+ Signed-off-by: Takashi Iwai Acked-by: Mika Westerberg Acked-by: Guenter Roeck Signed-off-by: Rafael J. Wysocki Signed-off-by: Liwei Song --- drivers/acpi/acpi_watchdog.c | 4 ++-- drivers/watchdog/wdat_wdt.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/acpi_watchdog.c b/drivers/acpi/acpi_watchdog.c index 8c4e0a18460a..87648aa645ba 100644 --- a/drivers/acpi/acpi_watchdog.c +++ b/drivers/acpi/acpi_watchdog.c @@ -74,10 +74,10 @@ void __init acpi_watchdog_init(void) res.start = gas->address; if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { res.flags = IORESOURCE_MEM; - res.end = res.start + ALIGN(gas->access_width, 4); + res.end = res.start + ALIGN(gas->access_width, 4) - 1; } else if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { res.flags = IORESOURCE_IO; - res.end = res.start + gas->access_width; + res.end = res.start + gas->access_width - 1; } else { pr_warn("Unsupported address space: %u\n", gas->space_id); diff --git a/drivers/watchdog/wdat_wdt.c b/drivers/watchdog/wdat_wdt.c index 6d1fbda0f461..0da9943d405f 100644 --- a/drivers/watchdog/wdat_wdt.c +++ b/drivers/watchdog/wdat_wdt.c @@ -392,7 +392,7 @@ static int wdat_wdt_probe(struct platform_device *pdev) memset(, 0, sizeof(r)); r.start = gas->address; - r.end = r.start + gas->access_width; + r.end = r.start + gas->access_width - 1; if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { r.flags = IORESOURCE_MEM; } else if (gas->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { -- 2.7.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto