date:20180508

Re: [yocto] [meta-selinux][PATCH 1/3] libselinux: refresh patches to fix QA warning

2018-05-08 Thread Yi Zhao


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

2018-05-08 Thread Zoran Stojsavljevic

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-Mixon  wrote:
> 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

2018-05-08 Thread Jeff Osier-Mixon

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-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

[yocto] How to create a build for ARM Cortex-A8, S5PV210

2018-05-08 Thread Denis

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

2018-05-08 Thread Alexander Kanavin


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

2018-05-08 Thread Khem Raj

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

2018-05-08 Thread Joe MacDonald

[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

2018-05-08 Thread Alan Martinovic

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

2018-05-08 Thread Iván Castell

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

2018-05-08 Thread Bruce Ashfield


merged.

Bruce

On 05/08/2018 05:30 AM, Liwei Song wrote:

From: Takashi Iwai 

commit 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

2018-05-08 Thread Bruce Ashfield


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

2018-05-08 Thread Alexander Kanavin


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

2018-05-08 Thread Zoran Stojsavljevic

> 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

2018-05-08 Thread Peter Kjellerstedt

> -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

2018-05-08 Thread Liwei Song

From: Takashi Iwai 

commit 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

Re: [yocto] [meta-selinux][PATCH 1/3] libselinux: refresh patches to fix QA warning

Re: [yocto] Yocto Project changes in progress

Re: [yocto] Yocto Project changes in progress

[yocto] How to create a build for ARM Cortex-A8, S5PV210

Re: [yocto] Native curl and SSL CA certificates

Re: [yocto] QT5.8 -qtwebengine SDK generation fails

Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core

[yocto] Autogenerate python dependencies after do_fetch

[yocto] Native curl and SSL CA certificates

Re: [linux-yocto] [4.12][PATCH] ACPI / watchdog: Fix off-by-one error at resource assignment

Re: [linux-yocto] v4.12.x - stable updates comprising v4.12.23

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

Re: [yocto] QT5.8 -qtwebengine SDK generation fails

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[linux-yocto] [4.12][PATCH] ACPI / watchdog: Fix off-by-one error at resource assignment

15 matches

Site Navigation

Mail list logo

Footer information