* Re: version of gdb in morty
From: Alexander Kanavin @ 2016-11-03 13:32 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <CAMKF1sp2Bft-bhJqT_C0siXFiHJyT8ouqoNQ2vmt-XGnJqw9Wg@mail.gmail.com>
On 11/03/2016 02:27 AM, Khem Raj wrote:
> I think doing an upgrade to 7.11.1 and Backporting that to morty is a
> reasonable option here
Update to 7.12 for master branch please.
Alex
^ permalink raw reply
* [krogoth][PATCH 1/2] qemu: Security fix CVE-2016-4439
From: Adrian Dudau @ 2016-11-03 13:18 UTC (permalink / raw)
To: openembedded-core
affects qemu < 2.7.0
Quick Emulator(Qemu) built with the ESP/NCR53C9x controller emulation
support is vulnerable to an OOB write access issue. The controller uses
16-byte FIFO buffer for command and data transfer. The OOB write occurs
while writing to this command buffer in routine get_cmd().
A privileged user inside guest could use this flaw to crash the Qemu
process resulting in DoS.
References:
----------
http://www.openwall.com/lists/oss-security/2016/05/19/4
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-4441
Signed-off-by: Adrian Dudau <adrian.dudau@enea.com>
---
.../recipes-devtools/qemu/qemu/CVE-2016-4441.patch | 78 ++++++++++++++++++++++
meta/recipes-devtools/qemu/qemu_2.5.0.bb | 1 +
2 files changed, 79 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch b/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
new file mode 100644
index 0000000..3cbe394
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
@@ -0,0 +1,78 @@
+From 6c1fef6b59563cc415f21e03f81539ed4b33ad90 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit <pjp@fedoraproject.org>
+Date: Thu, 19 May 2016 16:09:31 +0530
+Subject: [PATCH] esp: check dma length before reading scsi command(CVE-2016-4441)
+
+The 53C9X Fast SCSI Controller(FSC) comes with an internal 16-byte
+FIFO buffer. It is used to handle command and data transfer.
+Routine get_cmd() uses DMA to read scsi commands into this buffer.
+Add check to validate DMA length against buffer size to avoid any
+overrun.
+
+Fixes CVE-2016-4441.
+
+Upstream-Status: Backport
+
+Reported-by: Li Qiang <liqiang6-s@360.cn>
+Cc: qemu-stable@nongnu.org
+Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
+Message-Id: <1463654371-11169-3-git-send-email-ppandit@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Adrian Dudau <adrian.dudau@enea.com>
+---
+ hw/scsi/esp.c | 11 +++++++----
+ 1 files changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
+index 01497e6..591c817 100644
+--- a/hw/scsi/esp.c
++++ b/hw/scsi/esp.c
+@@ -82,7 +82,7 @@ void esp_request_cancelled(SCSIRequest *req)
+ }
+ }
+
+-static uint32_t get_cmd(ESPState *s, uint8_t *buf)
++static uint32_t get_cmd(ESPState *s, uint8_t *buf, uint8_t buflen)
+ {
+ uint32_t dmalen;
+ int target;
+@@ -92,6 +92,9 @@ static uint32_t get_cmd(ESPState *s, uint8_t *buf)
+ dmalen = s->rregs[ESP_TCLO];
+ dmalen |= s->rregs[ESP_TCMID] << 8;
+ dmalen |= s->rregs[ESP_TCHI] << 16;
++ if (dmalen > buflen) {
++ return 0;
++ }
+ s->dma_memory_read(s->dma_opaque, buf, dmalen);
+ } else {
+ dmalen = s->ti_size;
+@@ -166,7 +169,7 @@ static void handle_satn(ESPState *s)
+ s->dma_cb = handle_satn;
+ return;
+ }
+- len = get_cmd(s, buf);
++ len = get_cmd(s, buf, sizeof(buf));
+ if (len)
+ do_cmd(s, buf);
+ }
+@@ -180,7 +183,7 @@ static void handle_s_without_atn(ESPState *s)
+ s->dma_cb = handle_s_without_atn;
+ return;
+ }
+- len = get_cmd(s, buf);
++ len = get_cmd(s, buf, sizeof(buf));
+ if (len) {
+ do_busid_cmd(s, buf, 0);
+ }
+@@ -192,7 +195,7 @@ static void handle_satn_stop(ESPState *s)
+ s->dma_cb = handle_satn_stop;
+ return;
+ }
+- s->cmdlen = get_cmd(s, s->cmdbuf);
++ s->cmdlen = get_cmd(s, s->cmdbuf, sizeof(s->cmdbuf));
+ if (s->cmdlen) {
+ trace_esp_handle_satn_stop(s->cmdlen);
+ s->do_cmd = 1;
+--
+1.7.0.4
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
index ed8d911..58902b1 100644
--- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
@@ -26,6 +26,7 @@ SRC_URI += "file://configure-fix-Darwin-target-detection.patch \
file://CVE-2016-6351_p2.patch \
file://CVE-2016-4002.patch \
file://CVE-2016-5403.patch \
+ file://CVE-2016-4441.patch \
"
SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2"
SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
--
1.9.1
^ permalink raw reply related
* Re: version of gdb in morty
From: Burton, Ross @ 2016-11-03 14:06 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
In-Reply-To: <13e6f9fa-fc42-68cf-3961-33c43d26e13f@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 230 bytes --]
On 3 November 2016 at 13:32, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:
> Update to 7.12 for master branch please.
>
To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.
Ross
[-- Attachment #2: Type: text/html, Size: 647 bytes --]
^ permalink raw reply
* Re: version of gdb in morty
From: Mark Hatle @ 2016-11-03 15:29 UTC (permalink / raw)
To: Burton, Ross, Alexander Kanavin; +Cc: OE-core
In-Reply-To: <CAJTo0LayXt5s0d+Sho6HtWiU53vnoJ5=JaZPLz5hKDXsCB_jtw@mail.gmail.com>
On 11/3/16 9:06 AM, Burton, Ross wrote:
>
> On 3 November 2016 at 13:32, Alexander Kanavin
> <alexander.kanavin@linux.intel.com <mailto:alexander.kanavin@linux.intel.com>>
> wrote:
>
> Update to 7.12 for master branch please.
>
>
> To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.
I'm fine with this as well.. The third digit release is small enough of a
change, I don't think it will impact stability on such a new release.
--Mark
> Ross
>
>
^ permalink raw reply
* [PATCH v2] serf: Update to version 1.3.9
From: Fabio Berton @ 2016-11-03 15:34 UTC (permalink / raw)
To: openembedded-core
Change SRC_URI and UPSTREAM_CHECK_URI to use APACHE_MIRROR to download
serf from apache project page.
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
---
meta/recipes-support/serf/{serf_1.3.8.bb => serf_1.3.9.bb} | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-support/serf/{serf_1.3.8.bb => serf_1.3.9.bb} (68%)
diff --git a/meta/recipes-support/serf/serf_1.3.8.bb b/meta/recipes-support/serf/serf_1.3.9.bb
similarity index 68%
rename from meta/recipes-support/serf/serf_1.3.8.bb
rename to meta/recipes-support/serf/serf_1.3.9.bb
index c498d90..6ea14ac 100644
--- a/meta/recipes-support/serf/serf_1.3.8.bb
+++ b/meta/recipes-support/serf/serf_1.3.9.bb
@@ -1,12 +1,12 @@
SUMMARY = "High-Performance Asynchronous HTTP Client Library"
-SRC_URI = "http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/s/${BPN}/${BPN}_${PV}.orig.tar.gz \
+SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://norpath.patch \
file://env.patch"
-SRC_URI[md5sum] = "713beaf05d7f3329de121e218e2fcb93"
-SRC_URI[sha256sum] = "77134cd5010664ca023585bce50978bd4005906ed280ff889f591f86df7c59e4"
+SRC_URI[md5sum] = "370a6340ff20366ab088012cd13f2b57"
+SRC_URI[sha256sum] = "549c2d21c577a8a9c0450facb5cca809f26591f048e466552240947bdf7a87cc"
-UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/s/serf/"
+UPSTREAM_CHECK_URI = "${APACHE_MIRROR}/${BPN}/"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
--
2.1.4
^ permalink raw reply related
* using devtool for rebasing patches
From: Alexander Kanavin @ 2016-11-03 16:01 UTC (permalink / raw)
To: Paul Eggleton, Patches and discussions about the oe-core layer
Hello Paul,
it would be very useful if devtool offered support for rebasing source
patches when they fail to apply, but currently there does not seem to be
any such feature:
ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
Parsing recipes..done.
NOTE: Fetching libksba...
NOTE: Unpacking...
NOTE: Patching...
ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
checking file Makefile.am
Hunk #1 FAILED at 21.
1 out of 1 hunk FAILED
checking file configure.ac
Hunk #1 succeeded at 414 (offset 14 lines).
checking file ksba.pc.in
checking file src/ksba.m4
ERROR: Function failed: patch_do_patch
ak@kanavin-desktop:~/development/poky/build$
What devtool could do here is apply the patches that can be applied and
then partially apply the patches that fail. Then give the developer some
kind of UI for dealing with the rejected hunks (which typically means
finding the place in the target file where the changes should go and
then manually editing them in, while looking at the original patch).
Without this feature devtool is half as useful as it could be
particularly for recipe version updates.
Thanks,
Alex
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Christopher Larson @ 2016-11-03 16:29 UTC (permalink / raw)
To: Alexander Kanavin
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
In-Reply-To: <6511599a-ddb1-77b0-f42e-69afeaa60cae@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
On Thu, Nov 3, 2016 at 9:01 AM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:
> it would be very useful if devtool offered support for rebasing source
> patches when they fail to apply, but currently there does not seem to be
> any such feature:
>
> ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> Parsing recipes..done.
> NOTE: Fetching libksba...
> NOTE: Unpacking...
> NOTE: Patching...
> ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
> checking file Makefile.am
> Hunk #1 FAILED at 21.
> 1 out of 1 hunk FAILED
> checking file configure.ac
> Hunk #1 succeeded at 414 (offset 14 lines).
> checking file ksba.pc.in
> checking file src/ksba.m4
> ERROR: Function failed: patch_do_patch
> ak@kanavin-desktop:~/development/poky/build$
>
> What devtool could do here is apply the patches that can be applied and
> then partially apply the patches that fail. Then give the developer some
> kind of UI for dealing with the rejected hunks (which typically means
> finding the place in the target file where the changes should go and then
> manually editing them in, while looking at the original patch).
>
> Without this feature devtool is half as useful as it could be particularly
> for recipe version updates.
>
That would be useful, indeed.
git already provides such a UI, afaik devtool just needs to use git-am to
apply the patches, ideally passing -3 to it, and let the user use git am to
resolve and continue applying patches.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 2402 bytes --]
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Alexander Kanavin @ 2016-11-03 16:35 UTC (permalink / raw)
To: Christopher Larson
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANnYeGT9VVFBH3cNGUKnE_jPw8CDGv2YC_10-w5pe=WmKQ@mail.gmail.com>
On 11/03/2016 06:29 PM, Christopher Larson wrote:
> git already provides such a UI, afaik devtool just needs to use git-am
> to apply the patches, ideally passing -3 to it, and let the user use git
> am to resolve and continue applying patches.
I don't think git am has any UI that helps with rebasing the rejects,
and -3 is often not useful here, as we don't have the commit history, if
the source is coming from tarball.
What you need to do here is to use git am --reject, which would
partially apply the patch, then find all the *.rej files and let the
user manually edit them in, then complete the patch application with git
am --continue.
Alex
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Patrick Ohly @ 2016-11-03 16:52 UTC (permalink / raw)
To: Alexander Kanavin
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
In-Reply-To: <6511599a-ddb1-77b0-f42e-69afeaa60cae@linux.intel.com>
On Thu, 2016-11-03 at 18:01 +0200, Alexander Kanavin wrote:
> Hello Paul,
>
> it would be very useful if devtool offered support for rebasing source
> patches when they fail to apply
+1 for that.
I tried it the other way around: first "devtool modify", then rebasing
using git (which only works when the recipe fetches from a git repo),
and finally changing the recipe such that it refers to the version I
rebased onto. But that version change in the recipe confused "devtool
update-recipe" considerably (as in "added all patches between the
version", if I remember correctly).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Christopher Larson @ 2016-11-03 17:14 UTC (permalink / raw)
To: Alexander Kanavin
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
In-Reply-To: <86a0da96-542d-685b-cdd3-588df6fe7024@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:
> On 11/03/2016 06:29 PM, Christopher Larson wrote:
>
>> git already provides such a UI, afaik devtool just needs to use git-am
>> to apply the patches, ideally passing -3 to it, and let the user use git
>> am to resolve and continue applying patches.
>>
>
> I don't think git am has any UI that helps with rebasing the rejects, and
> -3 is often not useful here, as we don't have the commit history, if the
> source is coming from tarball.
>
Fairly sure that’s not actually correct. See below.
> What you need to do here is to use git am --reject, which would partially
> apply the patch, then find all the *.rej files and let the user manually
> edit them in, then complete the patch application with git am --continue.
With -3, it’ll merge it into the file with conflict markers, which is a lot
more pleasant to deal with than .rej files, even without the merge-base
being available.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 1855 bytes --]
^ permalink raw reply
* [PATCH 00/43] Krogoth-next pull request
From: Armin Kuster @ 2016-11-03 17:36 UTC (permalink / raw)
To: akuster808, openembedded-core
Please consider these changes for krogoth-next
The following changes since commit 40f4a6d075236265086cc79400dea3c14720383a:
bsp-guide: Updated the yocto-bsp create selections in the example. (2016-10-13 23:16:56 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib akuster/krogoth-next
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akuster/krogoth-next
Aníbal Limón (1):
bitbake: bb.event: fix infinite loop on print_ui_queue
Armin Kuster (2):
meta-linux-yocto: update to 4.1.33
meta-linux-yocto: update 4.4 to 4.4.26
Bruce Ashfield (7):
linux-yocto/4.1: update to 4.1.33
linux-yocto/4.4: update to v4.4.22
linux-yocto/4.1/4.4: remove innappropriate standard/base patches
linux-yocto/4.4/4.8: kernel config warning cleanups
linux-yocto/4.4: update to v4.4.26
linux-yocto/4.1: fix CVE-2016-5195 (dirtycow)
perf: adapt to Makefile.config
California Sullivan (4):
parselogs.py: Add amd_nb error to x86_common whitelist
parselogs.py: Add dmi and ioremap errors to ignore list for core2
parselogs.py: Ignore Skylake graphics firmware load errors on
genericx86-64
parselogs.py: Add disabling eDP error to x86_common whitelist
Christopher Larson (1):
perf: Fix to obey LD failure on qemux86-64
Ed Bartosh (1):
bitbake: event.py: output errors and warnings to stderr
Enrico Scholz (1):
bitbake: fetch: copy files with -H
Joshua Lock (1):
bitbake: event: prevent unclosed file warning in print_ui_queue
Juro Bystricky (3):
libgcc-common.inc: Fix broken symlinks for multilib SDK
gcc-runtime.inc: add CPP support for mips64-n32 tune
gcc-runtime.inc: Add CPP support for x86-64-x32 tune
Jussi Kukkonen (1):
This is a backport from master of 2 consecutive fixes.
Khem Raj (1):
binutils: Fix gas error with cfi_section inconsistencies
Markus Lehtonen (1):
rpm: prevent race in tempdir creation
Ola x Nilsson (2):
devtool: build_image: Fix recipe filter
devtool: Use the wildcard flag in update_recipe_patch
Pascal Bach (1):
glibc: fix CVE-2016-1234, CVE-2016-3075, CVE-2016-5417
Paul Eggleton (8):
devtool: update-recipe: fix --initial-rev option
devtool: reset: allow reset to work if the recipe file has been
deleted
recipetool: create: fix handling of github URLs
lib/oe/recipeutils: fix patch_recipe*() with empty input
recipetool: create: fix greedy regex that broke support for github
tarballs
oe-selftest: recipetool: add tests for git URL mangling
devtool: add: fix error message when only specifying a recipe name
classes/externalsrc: re-run do_configure when configure files change
Richard Purdie (3):
parselogs: Ignore amb_nb warning messages under qemux86*
parselogs: Ignore uvesafb timeouts
oeqa/parselogs: Don't use cwd for file transfers
Saul Wold (1):
archiver: fix gcc-source handling
Sona Sarmadi (2):
dropbear: fix multiple CVEs
bash: Security fix CVE-2016-0634
Sujith Haridasan (1):
perf: Fix to obey LD failure
Zheng Ruoqin (1):
bind: fix two CVEs
bitbake/lib/bb/event.py | 17 +-
bitbake/lib/bb/fetch2/__init__.py | 2 +-
.../recipes-kernel/linux/linux-yocto_4.1.bbappend | 17 +-
.../recipes-kernel/linux/linux-yocto_4.4.bbappend | 17 +-
meta/classes/archiver.bbclass | 5 +-
meta/classes/autotools.bbclass | 2 +
meta/classes/cmake.bbclass | 2 +
meta/classes/externalsrc.bbclass | 22 +
meta/lib/oe/recipeutils.py | 2 +-
meta/lib/oeqa/runtime/parselogs.py | 29 +-
meta/lib/oeqa/selftest/recipetool.py | 43 +
.../bind/bind/CVE-2016-2775.patch | 90 +
.../bind/bind/CVE-2016-2776.patch | 123 +
meta/recipes-connectivity/bind/bind_9.10.3-P3.bb | 2 +
meta/recipes-core/base-files/base-files/profile | 6 +-
meta/recipes-core/dropbear/dropbear.inc | 4 +
.../dropbear/dropbear/CVE-2016-7406.patch | 102 +
.../dropbear/dropbear/CVE-2016-7407.patch | 2486 ++++++++++++++++++++
.../dropbear/dropbear/CVE-2016-7408.patch | 101 +
.../dropbear/dropbear/CVE-2016-7409.patch | 27 +
meta/recipes-core/glibc/glibc/CVE-2016-1234.patch | 427 ++++
meta/recipes-core/glibc/glibc/CVE-2016-3075.patch | 37 +
meta/recipes-core/glibc/glibc/CVE-2016-5417.patch | 28 +
meta/recipes-core/glibc/glibc_2.23.bb | 3 +
meta/recipes-devtools/binutils/binutils-2.26.inc | 1 +
..._sections-check-to-only-consider-compact-.patch | 97 +
meta/recipes-devtools/gcc/gcc-runtime.inc | 18 +
meta/recipes-devtools/gcc/libgcc-common.inc | 8 +-
...more-verbose-error-logging-in-rpmTempFile.patch | 26 +-
.../rpmdb-prevent-race-in-tmpdir-creation.patch | 41 +
meta/recipes-devtools/rpm/rpm_5.4.16.bb | 1 +
.../recipes-extended/bash/bash/CVE-2016-0634.patch | 136 ++
meta/recipes-extended/bash/bash_4.3.30.bb | 1 +
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 6 +-
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 6 +-
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 6 +-
meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 6 +-
meta/recipes-kernel/linux/linux-yocto_4.1.bb | 20 +-
meta/recipes-kernel/linux/linux-yocto_4.4.bb | 20 +-
meta/recipes-kernel/perf/perf.bb | 13 +-
scripts/lib/devtool/build_image.py | 2 +-
scripts/lib/devtool/standard.py | 18 +-
scripts/lib/recipetool/create.py | 2 +-
43 files changed, 3923 insertions(+), 99 deletions(-)
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2016-2775.patch
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2016-2776.patch
create mode 100644 meta/recipes-core/dropbear/dropbear/CVE-2016-7406.patch
create mode 100644 meta/recipes-core/dropbear/dropbear/CVE-2016-7407.patch
create mode 100644 meta/recipes-core/dropbear/dropbear/CVE-2016-7408.patch
create mode 100644 meta/recipes-core/dropbear/dropbear/CVE-2016-7409.patch
create mode 100644 meta/recipes-core/glibc/glibc/CVE-2016-1234.patch
create mode 100644 meta/recipes-core/glibc/glibc/CVE-2016-3075.patch
create mode 100644 meta/recipes-core/glibc/glibc/CVE-2016-5417.patch
create mode 100644 meta/recipes-devtools/binutils/binutils/0015-Refine-.cfi_sections-check-to-only-consider-compact-.patch
create mode 100644 meta/recipes-devtools/rpm/rpm/rpmdb-prevent-race-in-tmpdir-creation.patch
create mode 100644 meta/recipes-extended/bash/bash/CVE-2016-0634.patch
--
2.3.5
^ permalink raw reply
* Re: [PATCH 1/3] linux-yocto/4.8: update to 4.8.6
From: Philip Balister @ 2016-11-03 17:53 UTC (permalink / raw)
To: Bruce Ashfield, richard.purdie; +Cc: openembedded-core
In-Reply-To: <85d6608fcafacaac093ccffc70b6315ef810fd0d.1478179369.git.bruce.ashfield@windriver.com>
I'd go bug Bruce directly, but I think the answer is of general interest.
How do I review the actual changes the version update makes?
At the moment, I'd like to look at the commits added to the kernel to
see if they are related to an issue I am having. I'm also wondering what
other stuff might change.
Philip
On 11/03/2016 09:25 AM, Bruce Ashfield wrote:
> Integrating the korg -stable release.
>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
> meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb | 6 +++---
> meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb | 6 +++---
> meta/recipes-kernel/linux/linux-yocto_4.8.bb | 20 ++++++++++----------
> 3 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
> index e51c9cdcca0e..26b309d8b8f4 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
> @@ -11,13 +11,13 @@ python () {
> raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
> }
>
> -SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
> +SRCREV_machine ?= "b99b6fac437104e206d30540a5cb12103049af1e"
> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>
> SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
>
> -LINUX_VERSION ?= "4.8.3"
> +LINUX_VERSION ?= "4.8.6"
>
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
> index c8ddbd93dc7f..63dd11baa19e 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
> @@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
>
> require recipes-kernel/linux/linux-yocto.inc
>
> -LINUX_VERSION ?= "4.8.3"
> +LINUX_VERSION ?= "4.8.6"
>
> KMETA = "kernel-meta"
> KCONF_BSP_AUDIT_LEVEL = "2"
>
> -SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
> +SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
> index 13778b9c4db6..03691982b1f0 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
> @@ -11,20 +11,20 @@ KBRANCH_qemux86 ?= "standard/base"
> KBRANCH_qemux86-64 ?= "standard/base"
> KBRANCH_qemumips64 ?= "standard/mti-malta64"
>
> -SRCREV_machine_qemuarm ?= "4cc544ad09ad704322cb66fe4ba197a6a05dc71f"
> -SRCREV_machine_qemuarm64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemumips ?= "c285969d4f9376a671167ecf397578c8ad3e6a75"
> -SRCREV_machine_qemuppc ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
> -SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
> +SRCREV_machine_qemuarm ?= "94d3e8675e2fcb09f29814a33ccf79df06149104"
> +SRCREV_machine_qemuarm64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemumips ?= "046ff6344eee25dcc0eea1214e0ad8771ddfabfb"
> +SRCREV_machine_qemuppc ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemux86 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemux86-64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemumips64 ?= "edcb167f91abc071cc98cbd762418ff7ab9d839b"
> +SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>
> SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; \
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
>
> -LINUX_VERSION ?= "4.8.3"
> +LINUX_VERSION ?= "4.8.6"
>
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
>
^ permalink raw reply
* Re: version of gdb in morty
From: Bas Mevissen @ 2016-11-03 17:59 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <d65d071b-28bc-5513-75f1-a609472e6a95@windriver.com>
On 03/11/16 16:29, Mark Hatle wrote:
> On 11/3/16 9:06 AM, Burton, Ross wrote:
>>
>> On 3 November 2016 at 13:32, Alexander Kanavin
>> <alexander.kanavin@linux.intel.com <mailto:alexander.kanavin@linux.intel.com>>
>> wrote:
>>
>> Update to 7.12 for master branch please.
>>
>>
>> To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.
>
> I'm fine with this as well.. The third digit release is small enough of a
> change, I don't think it will impact stability on such a new release.
>
+1
7.11.1 is bugfix only.
7.12 is removing some stuff that might cause breakage. The only new
thing worth mentioning is Rust support.
--
Bas.
^ permalink raw reply
* Re: [PATCH 1/3] linux-yocto/4.8: update to 4.8.6
From: Bruce Ashfield @ 2016-11-03 17:59 UTC (permalink / raw)
To: Philip Balister, richard.purdie; +Cc: openembedded-core
In-Reply-To: <1f3a4a9d-ff3a-a90b-6627-cecdcc51b398@balister.org>
On 2016-11-03 1:53 PM, Philip Balister wrote:
> I'd go bug Bruce directly, but I think the answer is of general interest.
>
> How do I review the actual changes the version update makes?
Sometimes I do a shortlog of the changes as part of my commit message.
It is sort of hit and miss .. i.e. when I think to do it.
>
> At the moment, I'd like to look at the commits added to the kernel to
> see if they are related to an issue I am having. I'm also wondering what
> other stuff might change.
Outside of inspecting the tree, the best thing I Can think of
is that I can do a shortlog of all the commits since the last
update.
Thoughts ?
Bruce
>
> Philip
>
> On 11/03/2016 09:25 AM, Bruce Ashfield wrote:
>> Integrating the korg -stable release.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>> meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb | 6 +++---
>> meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb | 6 +++---
>> meta/recipes-kernel/linux/linux-yocto_4.8.bb | 20 ++++++++++----------
>> 3 files changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
>> index e51c9cdcca0e..26b309d8b8f4 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
>> @@ -11,13 +11,13 @@ python () {
>> raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
>> }
>>
>> -SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
>> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
>> +SRCREV_machine ?= "b99b6fac437104e206d30540a5cb12103049af1e"
>> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>>
>> SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \
>> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
>>
>> -LINUX_VERSION ?= "4.8.3"
>> +LINUX_VERSION ?= "4.8.6"
>>
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
>> index c8ddbd93dc7f..63dd11baa19e 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
>> @@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
>>
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> -LINUX_VERSION ?= "4.8.3"
>> +LINUX_VERSION ?= "4.8.6"
>>
>> KMETA = "kernel-meta"
>> KCONF_BSP_AUDIT_LEVEL = "2"
>>
>> -SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
>> +SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
>> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>>
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
>> index 13778b9c4db6..03691982b1f0 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
>> @@ -11,20 +11,20 @@ KBRANCH_qemux86 ?= "standard/base"
>> KBRANCH_qemux86-64 ?= "standard/base"
>> KBRANCH_qemumips64 ?= "standard/mti-malta64"
>>
>> -SRCREV_machine_qemuarm ?= "4cc544ad09ad704322cb66fe4ba197a6a05dc71f"
>> -SRCREV_machine_qemuarm64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>> -SRCREV_machine_qemumips ?= "c285969d4f9376a671167ecf397578c8ad3e6a75"
>> -SRCREV_machine_qemuppc ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>> -SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>> -SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>> -SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
>> -SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
>> +SRCREV_machine_qemuarm ?= "94d3e8675e2fcb09f29814a33ccf79df06149104"
>> +SRCREV_machine_qemuarm64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
>> +SRCREV_machine_qemumips ?= "046ff6344eee25dcc0eea1214e0ad8771ddfabfb"
>> +SRCREV_machine_qemuppc ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
>> +SRCREV_machine_qemux86 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
>> +SRCREV_machine_qemux86-64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
>> +SRCREV_machine_qemumips64 ?= "edcb167f91abc071cc98cbd762418ff7ab9d839b"
>> +SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
>> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>>
>> SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; \
>> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
>>
>> -LINUX_VERSION ?= "4.8.3"
>> +LINUX_VERSION ?= "4.8.6"
>>
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>>
^ permalink raw reply
* [master][morty][PATCH 1/2] ltp: Fix QA warning
From: Jagadeesh Krishnanjanappa @ 2016-11-03 18:04 UTC (permalink / raw)
To: openembedded-core
It solves below QA issue WARNING while building ltp, when
LICENSE_CREATE_PACKAGE is set to "1"
-- snip --
WARNING: ltp-20160126-r0 do_package_qa: QA Issue: /opt/ltp/share/licenses/ltp/run_freezer.sh contained in package ltp-lic requires /bin/bash, but no providers found in RDEPENDS_ltp-lic? [file-rdeps]
-- snip --
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
---
meta/recipes-extended/ltp/ltp_20160126.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-extended/ltp/ltp_20160126.bb b/meta/recipes-extended/ltp/ltp_20160126.bb
index 7631e0e..c731f42 100644
--- a/meta/recipes-extended/ltp/ltp_20160126.bb
+++ b/meta/recipes-extended/ltp/ltp_20160126.bb
@@ -105,6 +105,7 @@ do_install(){
}
RDEPENDS_${PN} = "perl e2fsprogs-mke2fs python-core libaio bash gawk expect ldd"
+RDEPENDS_${PN}-lic = "bash"
FILES_${PN}-staticdev += "/opt/ltp/lib/libmem.a"
--
2.7.4
^ permalink raw reply related
* [master][morty][PATCH 2/2] hdparm: Fix QA warning
From: Jagadeesh Krishnanjanappa @ 2016-11-03 18:04 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1478196294-7594-1-git-send-email-jkrishnanjanappa@mvista.com>
It solves below QA issue WARNING while building hdparm, when
LICENSE_CREATE_PACKAGE is set to "1"
-- snip --
WARNING: hdparm-9.48-r0 do_package_qa: QA Issue: /usr/share/licenses/hdparm/wiper.sh contained in package hdparm-lic requires /bin/bash, but no providers found in RDEPENDS_hdparm-lic? [file-rdeps]
-- snip --
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
---
meta/recipes-extended/hdparm/hdparm_9.48.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-extended/hdparm/hdparm_9.48.bb b/meta/recipes-extended/hdparm/hdparm_9.48.bb
index cd85776..2c1e77d 100644
--- a/meta/recipes-extended/hdparm/hdparm_9.48.bb
+++ b/meta/recipes-extended/hdparm/hdparm_9.48.bb
@@ -38,3 +38,5 @@ do_install () {
oe_runmake 'DESTDIR=${D}' 'sbindir=${base_sbindir}' install
cp ${S}/wiper/wiper.sh ${D}/${bindir}
}
+
+RDEPENDS_${PN}-lic = "bash"
--
2.7.4
^ permalink raw reply related
* Re: using devtool for rebasing patches
From: Patrick Ohly @ 2016-11-03 19:14 UTC (permalink / raw)
To: Christopher Larson
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
In-Reply-To: <CABcZAN=6WvHcfyUj5hYmFG6nYoYTkYLrqO6s70v31bYNn85iXg@mail.gmail.com>
On Thu, 2016-11-03 at 10:14 -0700, Christopher Larson wrote:
>
> On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin
> <alexander.kanavin@linux.intel.com> wrote:
>
> What you need to do here is to use git am --reject, which
> would partially apply the patch, then find all the *.rej files
> and let the user manually edit them in, then complete the
> patch application with git am --continue.
>
>
> With -3, it’ll merge it into the file with conflict markers, which is
> a lot more pleasant to deal with than .rej files, even without the
> merge-base being available.
That's also what I would prefer.
To deal with recipes that have something other than git as source one
could create a local git repo with a branch that contains two commits
(old version and new version), apply the patches on a second branch on
top of the old version, then do the normal rebase with conflictstyle =
diff3. At least I find that configstyle useful and have it in my
~/.gitconfig.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Paul Eggleton @ 2016-11-03 19:24 UTC (permalink / raw)
To: Patrick Ohly
Cc: Christopher Larson,
Patches and discussions about the oe-core layer
In-Reply-To: <1478200444.13356.108.camel@intel.com>
On Thu, 03 Nov 2016 20:14:04 Patrick Ohly wrote:
> On Thu, 2016-11-03 at 10:14 -0700, Christopher Larson wrote:
> > On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin
> >
> > <alexander.kanavin@linux.intel.com> wrote:
> > What you need to do here is to use git am --reject, which
> > would partially apply the patch, then find all the *.rej files
> > and let the user manually edit them in, then complete the
> > patch application with git am --continue.
> >
> > With -3, it’ll merge it into the file with conflict markers, which is
> > a lot more pleasant to deal with than .rej files, even without the
> > merge-base being available.
>
> That's also what I would prefer.
>
> To deal with recipes that have something other than git as source one
> could create a local git repo with a branch that contains two commits
> (old version and new version), apply the patches on a second branch on
> top of the old version, then do the normal rebase with conflictstyle =
> diff3. At least I find that configstyle useful and have it in my
> ~/.gitconfig.
FYI this is what "devtool upgrade" already does. It's just that it's geared
towards upgrading so it expects the version to be changing at the same time.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Khem Raj @ 2016-11-03 19:27 UTC (permalink / raw)
To: Christopher Larson
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANnYeGT9VVFBH3cNGUKnE_jPw8CDGv2YC_10-w5pe=WmKQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2350 bytes --]
> On Nov 3, 2016, at 9:29 AM, Christopher Larson <clarson@kergoth.com> wrote:
>
>
> On Thu, Nov 3, 2016 at 9:01 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com <mailto:alexander.kanavin@linux.intel.com>> wrote:
> it would be very useful if devtool offered support for rebasing source patches when they fail to apply, but currently there does not seem to be any such feature:
>
> ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> Parsing recipes..done.
> NOTE: Fetching libksba...
> NOTE: Unpacking...
> NOTE: Patching...
> ERROR: Applying 'ksba-add-pkgconfig-support.pa <http://ksba-add-pkgconfig-support.pa/>tch' failed:
> checking file Makefile.am
> Hunk #1 FAILED at 21.
> 1 out of 1 hunk FAILED
> checking file configure.ac <http://configure.ac/>
> Hunk #1 succeeded at 414 (offset 14 lines).
> checking file ksba.pc.in <http://ksba.pc.in/>
> checking file src/ksba.m4
> ERROR: Function failed: patch_do_patch
> ak@kanavin-desktop:~/development/poky/build$
>
> What devtool could do here is apply the patches that can be applied and then partially apply the patches that fail. Then give the developer some kind of UI for dealing with the rejected hunks (which typically means finding the place in the target file where the changes should go and then manually editing them in, while looking at the original patch).
>
> Without this feature devtool is half as useful as it could be particularly for recipe version updates.
>
> That would be useful, indeed.
>
> git already provides such a UI, afaik devtool just needs to use git-am to apply the patches, ideally passing -3 to it, and let the user use git am to resolve and continue applying patches.
this seems good. Although, I have seen that all patches are not git am applicable, then I use git apply, something even that does not work, then third option is
to use patch < patch and this works if it does not work then patch needs manual work.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
[-- Attachment #1.2: Type: text/html, Size: 4013 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: version of gdb in morty
From: Khem Raj @ 2016-11-03 19:28 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LayXt5s0d+Sho6HtWiU53vnoJ5=JaZPLz5hKDXsCB_jtw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 575 bytes --]
> On Nov 3, 2016, at 7:06 AM, Burton, Ross <ross.burton@intel.com> wrote:
>
>
> On 3 November 2016 at 13:32, Alexander Kanavin <alexander.kanavin@linux.intel.com <mailto:alexander.kanavin@linux.intel.com>> wrote:
> Update to 7.12 for master branch please.
>
> To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.
yep
>
> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
[-- Attachment #1.2: Type: text/html, Size: 1689 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Paul Eggleton @ 2016-11-03 19:29 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <6511599a-ddb1-77b0-f42e-69afeaa60cae@linux.intel.com>
Hi Alex,
On Thu, 03 Nov 2016 18:01:27 Alexander Kanavin wrote:
> it would be very useful if devtool offered support for rebasing source
> patches when they fail to apply, but currently there does not seem to be
> any such feature:
>
> ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> Parsing recipes..done.
> NOTE: Fetching libksba...
> NOTE: Unpacking...
> NOTE: Patching...
> ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
> checking file Makefile.am
> Hunk #1 FAILED at 21.
> 1 out of 1 hunk FAILED
> checking file configure.ac
> Hunk #1 succeeded at 414 (offset 14 lines).
> checking file ksba.pc.in
> checking file src/ksba.m4
> ERROR: Function failed: patch_do_patch
> ak@kanavin-desktop:~/development/poky/build$
>
> What devtool could do here is apply the patches that can be applied and
> then partially apply the patches that fail. Then give the developer some
> kind of UI for dealing with the rejected hunks (which typically means
> finding the place in the target file where the changes should go and
> then manually editing them in, while looking at the original patch).
>
> Without this feature devtool is half as useful as it could be
> particularly for recipe version updates.
"devtool upgrade" is designed specifically to handle the upgrade case and
tries to rebase the old patches onto the new version, putting you into
resolution mode with "git am" if it fails to apply a patch. I appreciate that
you may now be working through sorting out all of the patches to reduce the
fuzziness when applying, and that won't help in that scenario, but it would
definitely be worth considering for upgrades.
I'm open to implementing better support for handling patch application failure
for devtool modify - in fact there is a bug open for just that:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8325
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: using devtool for rebasing patches
From: Paul Eggleton @ 2016-11-03 19:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1480827.LzmdYstA2d@peggleto-mobl.ger.corp.intel.com>
On Fri, 04 Nov 2016 08:29:26 Paul Eggleton wrote:
> Hi Alex,
>
> On Thu, 03 Nov 2016 18:01:27 Alexander Kanavin wrote:
> > it would be very useful if devtool offered support for rebasing source
> > patches when they fail to apply, but currently there does not seem to be
> > any such feature:
> >
> > ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> > Parsing recipes..done.
> > NOTE: Fetching libksba...
> > NOTE: Unpacking...
> > NOTE: Patching...
> > ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
> > checking file Makefile.am
> > Hunk #1 FAILED at 21.
> > 1 out of 1 hunk FAILED
> > checking file configure.ac
> > Hunk #1 succeeded at 414 (offset 14 lines).
> > checking file ksba.pc.in
> > checking file src/ksba.m4
> > ERROR: Function failed: patch_do_patch
> > ak@kanavin-desktop:~/development/poky/build$
> >
> > What devtool could do here is apply the patches that can be applied and
> > then partially apply the patches that fail. Then give the developer some
> > kind of UI for dealing with the rejected hunks (which typically means
> > finding the place in the target file where the changes should go and
> > then manually editing them in, while looking at the original patch).
> >
> > Without this feature devtool is half as useful as it could be
> > particularly for recipe version updates.
>
> "devtool upgrade" is designed specifically to handle the upgrade case and
> tries to rebase the old patches onto the new version, putting you into
> resolution mode with "git am" if it fails to apply a patch. I appreciate
> that you may now be working through sorting out all of the patches to
> reduce the fuzziness when applying, and that won't help in that scenario,
> but it would definitely be worth considering for upgrades.
>
> I'm open to implementing better support for handling patch application
> failure for devtool modify - in fact there is a bug open for just that:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8325
(Although admittedly that was mostly for an earlier issue - we ought to add a
bit of description of where to go from here.)
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [master][morty][PATCH 1/2] ltp: Fix QA warning
From: Burton, Ross @ 2016-11-03 19:39 UTC (permalink / raw)
To: Jagadeesh Krishnanjanappa; +Cc: OE-core
In-Reply-To: <1478196294-7594-1-git-send-email-jkrishnanjanappa@mvista.com>
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
On 3 November 2016 at 18:04, Jagadeesh Krishnanjanappa <
jkrishnanjanappa@mvista.com> wrote:
> WARNING: ltp-20160126-r0 do_package_qa: QA Issue:
> /opt/ltp/share/licenses/ltp/run_freezer.sh contained in package ltp-lic
> requires /bin/bash, but no providers found in RDEPENDS_ltp-lic? [file-rdeps]
>
So the common problem "if PN-lic contains a license statement embedded in a
file with a hashbang, file-rdeps is triggered", so I'd say file-rdeps
should be added to INSANE_SKIP_${PN}-lic in bitbake.conf instead of dealing
with this per recipe.
Ross
[-- Attachment #2: Type: text/html, Size: 988 bytes --]
^ permalink raw reply
* Re: [PATCH v2] serf: Update to version 1.3.9
From: Burton, Ross @ 2016-11-03 19:40 UTC (permalink / raw)
To: Fabio Berton; +Cc: OE-core
In-Reply-To: <1478187243-17488-1-git-send-email-fabio.berton@ossystems.com.br>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
On 3 November 2016 at 15:34, Fabio Berton <fabio.berton@ossystems.com.br>
wrote:
> -UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/s/serf/"
> +UPSTREAM_CHECK_URI = "${APACHE_MIRROR}/${BPN}/"
>
As all the tarballs are in a single directory you can probably just delete
this line (though please do check with bitbake serf -c checkpkg).
Ross
[-- Attachment #2: Type: text/html, Size: 791 bytes --]
^ permalink raw reply
* Re: Sanity check fails with 'ccache'
From: Andre McCurdy @ 2016-11-03 19:44 UTC (permalink / raw)
To: Enrico Scholz, jeremy.rosen; +Cc: OE Core mailing list
In-Reply-To: <lywpgnv3f4.fsf@ensc-virt.intern.sigma-chemnitz.de>
On Tue, Nov 1, 2016 at 4:35 AM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> Hi,
>
> with 'morty', sanity check fails with
>
> | Please install the following missing utilities: C Compiler (ccache gcc ),C++ Compiler (ccache g++ )
>
> I think, parts of 89f55bf8e9d633cfb508a0885a462afb561c7cee should be
> reverted.
+1
The sanity check changes cause problems when ccache is enabled:
http://git.openembedded.org/openembedded-core/commit/?id=89f55bf8e9d633cfb508a0885a462afb561c7cee
>
> Enrico
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox