* Re: [yocto] Attention all: patches for upstream source will be applied with stricter criteria for context
From: Alexander Kanavin @ 2016-10-21 15:13 UTC (permalink / raw)
To: akuster, Patches and discussions about the oe-core layer
In-Reply-To: <62045b91-79db-cc5e-c372-70041b7fcdaa@mvista.com>
On 10/21/2016 06:08 PM, akuster wrote:
>> while updating gnutls to a newer version I came across a rather
>> serious issue: the way we patch source code is very lenient about the
>> context for the lines to be changed. Basically, it's enough for one
>> line before and after the changed line to match, because patch
>> command's default setting for 'fuzz factor' allows it. If these lines
>> happen to be whitespace or braces, then there's nothing to prevent the
>> patch from being applied incorrectly.
>>
>> Here's a particularly nasty example of this happening completely
>> silently (compile step works fine too), with security implications:
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
>>
>> I think this absolutely needs to be fixed.
>
> Is there a target milestone for this change?
Currently the plan is to fix all of oe-core and send out a patchset,
including the stricter fuzz setting in time for 2.3 M1. Here's the branch:
https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/fix-patch-fuzz
>> The downside is that this will break a lot of patches across all
>> layers - after setting the fuzz to zero in oe-core we have 87 recipes
>> that fail to be patched. Maxin and I are currently going through them
>> one by one and getting them fixed.
>
> Is this going to impact the 2.2 release?
If we find any patches that are applied incorrectly (as opposed to just
having out of date context but still applied correctly), then the fixes
will be backported as well.
Alex
^ permalink raw reply
* Re: [PATCH 18/19] webkitgtk: update to 2.14.1
From: Alexander Kanavin @ 2016-10-21 15:17 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LYqYBvyYnkE2Mud6DykHxbhD0ORvKCa7kUAZLfKqy_zog@mail.gmail.com>
On 10/20/2016 12:27 PM, Burton, Ross wrote:
> I should have finished reading the report before hitting send:
>
> packages/corei7-64-poky-linux/webkitgtk/webkitgtk: FILELIST: removed
> "/usr/lib/libwebkit2gtk-4.0.so.37.13.11
> /usr/lib/libjavascriptcoregtk-4.0.so.18.3.13" added
> "/usr/lib/libjavascriptcoregtk-4.0.so.18.4.8
> /usr/libexec/webkit2gtk-4.0/MiniBrowser /usr/libexec/webkit2gtk-4.0/jsc
> /usr/lib/libwebkit2gtk-4.0.so.37.14.8"
>
> If libexecdir is the right place for these then we can remove
> lib_package, otherwise the question is why are they in there and can
> they be moved back to bindir.
They did it on purpose, no idea why:
What's new in WebKitGTK+ 2.14.1?
- MiniBrowser and jsc binaries are now installed in pkglibexecdir
instead of bindir.
I've dropped the lib_package.
Alex
^ permalink raw reply
* Yocto Project Status WW43
From: Jolley, Stephen K @ 2016-10-21 15:26 UTC (permalink / raw)
To: yocto@yoctoproject.org, openembedded-core@lists.openembedded.org
[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]
Current Dev Position: YP 2.2 M4
Next Deadline: YP 2.2 M4 which was Oct. 3rd (5:00pm GMT)
SWAT team rotation: Paul -> Ross
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Key Status/Updates:
* Travel for ELC-E did interrupt these status report, apologies for that. Some of the builds were tricky to debug and/or fix due to some communication issues the travel didn't help with too.
* 2.2 rc4 is currently in QA. Current status is at: https://wiki.yoctoproject.org/wiki/2.2_QA_Status
* At time of press, the runqemu issues are concerning but perhaps not enough to delay the release, instead being fixed on the branch immediately afterwards, assuming fixes are available by then.
* 2.2 rc1-3 had various issues, some autobuilder related, some were new and interesting bugs we'd never seen before during the release build, or an intermittent bug we'd not seen for months in one case.
* The Morty release branches are in a position to diverge and we have started to look at queuing the patches that are already being submitted in -next and mut builds for master.
* 2.3 planning is underway and RP will send more thoughts on the plans for that in the next couple of weeks. Recipe specific sysroots look like one desired feature for multiple reasons and there was good discussion and feedback and OEDEM
* The discussion at OEDEM has great notes (thanks Jan in particular): http://openembedded.org/wiki/OEDEM_2016#Minutes
* Whilst the defect density was decreasing, there has now been an uptick in the number of defects and things are rising again.
* Several good performance issues were found and addressed, a separate email was sent on that topic.
* Proposed 2.3 dates are below but this isn't 100% confirmed yet.
Key YP 2.2 Dates:
* YP 2.2 M4 release would be: 10/28/16
Proposed upcoming releases after YP 2.2 are:
Milestone
Cutoff
Release
YP 2.0.3
11/7/2016
11/18/2016
YP 2.1.2
11/28/2016
12/9/2016
YP 2.3 M1
12/12/2016
12/23/2016
YP 2.2.1
1/9/2017
1/20/2017
YP 2.3 M2
1/23/2017
2/3/2017
YP 2.3 M3
2/27/2017
3/10/2017
YP 2.3 M4
4/3/2017
4/28/2017
YP 2.3
4/3/2017
4/28/2017
YP 2.1.3
5/8/2017
5/19/2017
YP 2.2.2
5/15/2017
5/30/2017
Tracking Metrics:
WDD 2306 (last week 2289)
(https://wiki.yoctoproject.org/charts/combo.html)
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features
[If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
* Work Telephone: (503) 712-0534
* Cell: (208) 244-4460
* Email: stephen.k.jolley@intel.com
[-- Attachment #2: Type: text/html, Size: 36114 bytes --]
^ permalink raw reply
* Re: [yocto] Yocto Project Status WW43
From: akuster808 @ 2016-10-21 15:32 UTC (permalink / raw)
To: Jolley, Stephen K, yocto@yoctoproject.org,
openembedded-core@lists.openembedded.org
In-Reply-To: <9ADD3FDE8B189B4AA2F8A3C711F8155E5729D82D@fmsmsx111.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3704 bytes --]
Stephen,
On 10/21/2016 08:26 AM, Jolley, Stephen K wrote:
>
> Current Dev Position: YP 2.2 M4
>
> Next Deadline: YP 2.2 M4 which was Oct. 3rd (5:00pm GMT)
>
> SWAT team rotation: Paul -> Ross
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
> Key Status/Updates:
>
> ·Travel for ELC-E did interrupt these status report, apologies for
> that. Some of the builds were tricky to debug and/or fix due to some
> communication issues the travel didn’t help with too.
>
> ·2.2 rc4 is currently in QA. Current status is at:
> https://wiki.yoctoproject.org/wiki/2.2_QA_Status
>
> ·At time of press, the runqemu issues are concerning but perhaps not
> enough to delay the release, instead being fixed on the branch
> immediately afterwards, assuming fixes are available by then.
>
> ·2.2 rc1-3 had various issues, some autobuilder related, some were new
> and interesting bugs we’d never seen before during the release build,
> or an intermittent bug we’d not seen for months in one case.
>
> ·The Morty release branches are in a position to diverge and we have
> started to look at queuing the patches that are already being
> submitted in -next and mut builds for master.
>
> ·2.3 planning is underway and RP will send more thoughts on the plans
> for that in the next couple of weeks. Recipe specific sysroots look
> like one desired feature for multiple reasons and there was good
> discussion and feedback and OEDEM
>
> ·The discussion at OEDEM has great notes (thanks Jan in particular):
> http://openembedded.org/wiki/OEDEM_2016#Minutes
>
> ·Whilst the defect density was decreasing, there has now been an
> uptick in the number of defects and things are rising again.
>
> ·Several good performance issues were found and addressed, a separate
> email was sent on that topic.
>
> ·Proposed 2.3 dates are below but this isn’t 100% confirmed yet.
>
> Key YP 2.2 Dates:
>
> ·YP 2.2 M4 release would be: 10/28/16
>
> Proposed upcoming releases after YP 2.2 are:
>
> Milestone
>
>
>
> Cutoff
>
>
>
> Release
>
> YP 2.0.3
>
>
>
> 11/7/2016
>
>
>
> 11/18/2016
>
> YP 2.1.2
>
>
>
> 11/28/2016
>
>
>
> 12/9/2016
>
> YP 2.3 M1
>
>
>
> 12/12/2016
>
>
>
> 12/23/2016
>
> YP 2.2.1
>
>
>
> 1/9/2017
>
>
>
> 1/20/2017
>
> YP 2.3 M2
>
>
>
> 1/23/2017
>
>
>
> 2/3/2017
>
> YP 2.3 M3
>
>
>
> 2/27/2017
>
>
>
> 3/10/2017
>
> YP 2.3 M4
>
>
>
> 4/3/2017
>
>
>
> 4/28/2017
>
> YP 2.3
>
>
>
> 4/3/2017
>
>
>
> 4/28/2017
>
> YP 2.1.3
>
>
>
> 5/8/2017
>
>
>
> 5/19/2017
>
> YP 2.2.2
>
>
>
> 5/15/2017
>
>
>
> 5/30/2017
>
These are helpful.
Thanks
Armin
>
> Tracking Metrics:
>
> WDD 2306 (last week 2289)
>
> (https://wiki.yoctoproject.org/charts/combo.html)
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features
>
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
> Thanks,
>
> */Stephen K. Jolley/**//*
>
> *Yocto Project Program Manager*
>
> *INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 *
>
> (*Work Telephone*: (503) 712-0534
>
> (*Cell*: (208) 244-4460
>
> * *Email*:_stephen.k.jolley@intel.com_
>
>
>
[-- Attachment #2: Type: text/html, Size: 43082 bytes --]
^ permalink raw reply
* [PATCH v2] linux-yocto/4.8: update to v4.8.3
From: Bruce Ashfield @ 2016-10-21 15:35 UTC (permalink / raw)
To: richard.purdie; +Cc: openembedded-core
Integrating the korg -stable release
One commit of note is the fix for CVE-2016-5195 (http://dirtycow.ninja/):
mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
The remaining changes are covered by the following shortlog export:
mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
Make __xfs_xattr_put_listen preperly report errors.
scsi: configure runtime pm before calling device_add in scsi_add_host_with_dma
v4l: rcar-fcp: Don't force users to check for disabled FCP support
Linux 4.8.2
tpm_crb: fix crb_req_canceled behavior
tpm: fix a race condition in tpm2_unseal_trusted()
ima: use file_dentry()
Bluetooth: Add a new 04ca:3011 QCA_ROME device
ARM: cpuidle: Fix error return code
ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs
ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs
ARM: dts: mvebu: armada-390: add missing compatibility string and bracket
ARM: fix delays
x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access
x86/mm/pkeys: Do not skip PKRU register if debug registers are not used
arch/x86: Handle non enumerated CPU after physical hotplug
x86/apic: Get rid of apic_version[] array
x86/platform/intel-mid: Keep SRAM powered on at boot
x86/platform/intel-mid: Add Intel Penwell to ID table
x86/cpu: Rename Merrifield2 to Moorefield
x86/pkeys: Make protection keys an "eager" feature
x86/irq: Prevent force migration of irqs which are not in the vector domain
x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
arm64: fix dump_backtrace/unwind_frame with NULL tsk
KVM: PPC: BookE: Fix a sanity check
KVM: arm/arm64: vgic: Don't flush/sync without a working vgic
KVM: arm64: Require in-kernel irqchip for PMU support
KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
xen/x86: Update topology map for PV VCPUs
mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
mfd: 88pm80x: Double shifting bug in suspend/resume
mfd: atmel-hlcdc: Do not sleep in atomic context
mfd: rtsx_usb: Avoid setting ucr->current_sg.status
ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID
ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants
ALSA: ali5451: Fix out-of-bound position reporting
phy: sun4i-usb: Use spinlock to guard phyctl register access
usb: dwc3: fix Clear Stall EP command failure
timekeeping: Fix __ktime_get_fast_ns() regression
usb: storage: fix runtime pm issue in usb_stor_probe2
Linux 4.8.1
ALSA: hda - Add the top speaker pin config for HP Spectre x360
ALSA: hda - Fix headset mic detection problem for several Dell laptops
ALSA: hda - Adding one more ALC255 pin definition for headset problem
Revert "usbtmc: convert to devm_kzalloc"
USB: serial: cp210x: Add ID for a Juniper console
usb: usbip: vudc: fix left shift overflow
Staging: fbtft: Fix bug in fbtft-core
usb: misc: legousbtower: Fix NULL pointer deference
Using BUG_ON() as an assert() is _never_ acceptable
arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP
Using BUG_ON() as an assert() is _never_ acceptable
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
Josh suggested that I highlight the dirtycow CVE fix, so I've spun a v2
patch for this update that has much more information.
Bruce
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 fc1c40caf7b2..00c3d2c7bc1f 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 ?= "b266f7ba78f0cb3d7073e1bf7bd7dfc92bec7431"
-SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
+SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
+SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
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"
+LINUX_VERSION ?= "4.8.3"
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 41ff5637ec59..799c3f37577d 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"
+LINUX_VERSION ?= "4.8.3"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
+SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
+SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
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 5738f4974b9b..56fbfc7001bf 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 ?= "f46e49344b4c66a6f0917c5a2e9a1d146176519d"
-SRCREV_machine_qemuarm64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_qemumips ?= "5a299402ae58d61429ab091f94748550efe45858"
-SRCREV_machine_qemuppc ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_qemux86 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_qemux86-64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_qemumips64 ?= "674818dad577cdfc23c6c857aa2b769fc64e379c"
-SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
+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 ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
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"
+LINUX_VERSION ?= "4.8.3"
PV = "${LINUX_VERSION}+git${SRCPV}"
--
2.5.0
^ permalink raw reply related
* Re: [PATCH] texi2html: Allow compiling out-of-source
From: Christopher Larson @ 2016-10-21 16:11 UTC (permalink / raw)
To: Olaf Mandel; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <1477057467-25114-1-git-send-email-o.mandel@menlosystems.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Fri, Oct 21, 2016 at 6:44 AM, Olaf Mandel <o.mandel@menlosystems.com>
wrote:
> Compiling texi2html 5.0 out-of-source with USE_NLS set to no failed
> because it trieed to copy from srcdir without using that variable.
> Fix this issue.
>
> No need to send upstream: current trunk already contains this.
>
> Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
>
Missing Upstream-Status in the patch file.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 1078 bytes --]
^ permalink raw reply
* Re: [PATCH] useradd-staticids.bbclass: catch missing uid/gid exceptions
From: Christopher Larson @ 2016-10-21 16:12 UTC (permalink / raw)
To: Mikko Ylinen; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <20161021070545.19812-1-mikko.ylinen@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]
On Fri, Oct 21, 2016 at 12:05 AM, Mikko Ylinen <mikko.ylinen@intel.com>
wrote:
> The change to get rid of FuncFailed exceptions changed the behavior
> of how missing uid/gid error are be handled. Instead of catching
> the exception and handling that via bb.parse.SkipPackage(), a fatal
> error was called.
>
> This won't work with recipes that are unused and therefore do not have
> UID/GIDs defined. The problem triggers when parsing all recipes (e.g.,
> oe-selftest runs bitbake -p).
>
> The right way to handle this is to raise bb.parse.SkipPackage(). This
> will error correctly once the recipe is needed.
>
> Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
> ---
> meta/classes/useradd-staticids.bbclass | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/useradd-staticids.bbclass
> b/meta/classes/useradd-staticids.bbclass
> index afb580a..4162774 100644
> --- a/meta/classes/useradd-staticids.bbclass
> +++ b/meta/classes/useradd-staticids.bbclass
> @@ -53,8 +53,7 @@ def update_useradd_static_config(d):
> def handle_missing_id(id, type, pkg):
> # For backwards compatibility we accept "1" in addition to "error"
> if d.getVar('USERADD_ERROR_DYNAMIC', True) == 'error' or
> d.getVar('USERADD_ERROR_DYNAMIC', True) == '1':
> - #bb.error("Skipping recipe %s, package %s which adds %sname
> %s does not have a static ID defined." % (d.getVar('PN', True), pkg, type,
> id))
> - bb.fatal("%s - %s: %sname %s does not have a static ID
> defined." % (d.getVar('PN', True), pkg, type, id))
> + raise NotImplementedError("%s - %s: %sname %s does not have a
> static ID defined. Skipping it." % (d.getVar('PN', True), pkg, type, id))
> elif d.getVar('USERADD_ERROR_DYNAMIC', True) == 'warn':
> bb.warn("%s - %s: %sname %s does not have a static ID
> defined." % (d.getVar('PN', True), pkg, type, id))
>
> @@ -323,7 +322,7 @@ python __anonymous() {
> and not bb.data.inherits_class('native', d):
> try:
> update_useradd_static_config(d)
> - except bb.build.FuncFailed as f:
> + except NotImplementedError as f:
> bb.debug(1, "Skipping recipe %s: %s" % (d.getVar('PN', True),
> f))
> raise bb.parse.SkipPackage(f)
>
NotImplementedError is not the right exception for this.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 3422 bytes --]
^ permalink raw reply
* [PATCH v2] texi2html: Allow compiling out-of-source
From: Olaf Mandel @ 2016-10-21 16:36 UTC (permalink / raw)
To: openembedded-core; +Cc: Christopher Larson, Olaf Mandel
In-Reply-To: <CABcZANnh3P7JAiigdGpafaBt2N6UCDj1T2JCFDDi7hLgjs-EUw@mail.gmail.com>
Compiling texi2html 5.0 out-of-source with USE_NLS set to no failed
because it tried to copy from srcdir without using that variable.
Fix this issue and add a reference to the upstream commit.
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
---
.../files/0001-Allow-compiling-out-of-source.patch | 39 ++++++++++++++++++++++
meta/recipes-extended/texi2html/texi2html_5.0.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644 meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch
diff --git a/meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch b/meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch
new file mode 100644
index 0000000..0cf025f
--- /dev/null
+++ b/meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch
@@ -0,0 +1,39 @@
+From: Olaf Mandel <o.mandel@menlosystems.com>
+Date: Fri, 21 Oct 2016 13:04:44 +0000
+Subject: [PATCH] Allow compiling out-of-source
+
+Upstream-Status: Backport of [svn://svn.sv.gnu.org/texinfo/trunk r3602]
+---
+ Makefile.am | 2 +-
+ Makefile.in | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 3447463..c9b5b5c 100644
+--- a/Makefile.am
++++ b/Makefile.am
+@@ -208,7 +208,7 @@ i18n/en.thl i18n/: $(po_document_dir)/po_document/$(PACKAGE)_document.pot
+ done; \
+ msgexec -i $< "$(srcdir)/gettext_to_separated.pl" | "$(srcdir)/separated_to_hash.pl" en > i18n/en.thl; \
+ else \
+- cp -p i18n_ref/*.thl i18n; \
++ cp -p "$(srcdir)/i18n_ref/"*.thl i18n; \
+ fi
+
+ i18n_ref:
+diff --git a/Makefile.in b/Makefile.in
+index 4264b37..a13f84d 100644
+--- a/Makefile.in
++++ b/Makefile.in
+@@ -1126,7 +1126,7 @@ i18n/en.thl i18n/: $(po_document_dir)/po_document/$(PACKAGE)_document.pot
+ done; \
+ msgexec -i $< "$(srcdir)/gettext_to_separated.pl" | "$(srcdir)/separated_to_hash.pl" en > i18n/en.thl; \
+ else \
+- cp -p i18n_ref/*.thl i18n; \
++ cp -p "$(srcdir)/i18n_ref/"*.thl i18n; \
+ fi
+
+ i18n_ref:
+--
+2.1.4
+
diff --git a/meta/recipes-extended/texi2html/texi2html_5.0.bb b/meta/recipes-extended/texi2html/texi2html_5.0.bb
index eac289e..ae64816 100644
--- a/meta/recipes-extended/texi2html/texi2html_5.0.bb
+++ b/meta/recipes-extended/texi2html/texi2html_5.0.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
PR = "r2"
SRC_URI = "${SAVANNAH_GNU_MIRROR}/texi2html/${BPN}-${PV}.tar.bz2 \
+ file://0001-Allow-compiling-out-of-source.patch \
"
SRC_URI[md5sum] = "f15ac876fcdc8be865b16535f480aa54"
--
2.1.4
^ permalink raw reply related
* Re: [yocto] Attention all: patches for upstream source will be applied with stricter criteria for context
From: Khem Raj @ 2016-10-21 17:05 UTC (permalink / raw)
To: Alexander Kanavin
Cc: Yocto Project, openembedded-devel@lists.openembedded.org,
Patches and discussions about the oe-core layer
In-Reply-To: <03b5e98b-0724-daa2-8f78-ab4624f52752@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
> On Oct 21, 2016, at 5:55 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
>
> Hello all,
>
> while updating gnutls to a newer version I came across a rather serious issue: the way we patch source code is very lenient about the context for the lines to be changed. Basically, it's enough for one line before and after the changed line to match, because patch command's default setting for 'fuzz factor' allows it. If these lines happen to be whitespace or braces, then there's nothing to prevent the patch from being applied incorrectly.
>
> Here's a particularly nasty example of this happening completely silently (compile step works fine too), with security implications:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
>
> I think this absolutely needs to be fixed. The downside is that this will break a lot of patches across all layers - after setting the fuzz to zero in oe-core we have 87 recipes that fail to be patched. Maxin and I are currently going through them one by one and getting them fixed.
perhaps a list of the recipes, with steps to configure fuzz factor on wiki would enable other folks to
fix them especially the recipe maintainers should care.
>
> Regards,
> Alex
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* [PATCH 0/1] Add 'task-time' buildstats helper script
From: Ulf Magnusson @ 2016-10-21 19:22 UTC (permalink / raw)
To: openembedded-core
If this goes in, I could also submit some documentation to the manuals. I
suspect many people don't use the buildstats since getting useful information
out of them is a bit of work.
Ulf Magnusson (1):
task-time: Add simple buildstats analysis script
scripts/task-time | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 132 insertions(+)
create mode 100755 scripts/task-time
--
2.7.4
^ permalink raw reply
* [PATCH 1/1] task-time: Add simple buildstats analysis script
From: Ulf Magnusson @ 2016-10-21 19:22 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1477077754-6211-1-git-send-email-ulfalizer@gmail.com>
The 'task-time' Python script is used for simple manual analysis of
buildstats. It displays task timing information in the same format (and
using the same calculation) as the Bash 'time' builtin, and can
optionally sort tasks by real (wall-clock), user (user space CPU), or
sys (kernel CPU) time used.
The timing information comes from the getrusage(2) fields added by
commit adfdca4df18f ("buildstats: Improve to add getrusage data and
corrected IO stats"). That commit is required for the script to work.
Example 1: Running 'task-time' on a specific task buildstat:
$ task-time ./20161005235448/gettext-0.16.1-r6/do_compile
./20161005235448/gettext-0.16.1-r6/do_compile:
real 0m54.560s
user 0m46.028s
sys 0m2.772s
Example 2: Running 'task-time' on a directory, sorting on wall-clock
time:
$ task-time tmp/buildstats/20161018083535 --sort real
tmp/buildstats/20161018083535/bash-4.3.30-r0/do_fetch:
real 10m59.140s
user 0m1.152s
sys 0m0.320s
tmp/buildstats/20161018083535/readline-native-6.3-r0/do_fetch:
real 8m57.310s
user 0m0.860s
sys 0m0.288s
tmp/buildstats/20161018083535/perl-5.22.1-r0/do_compile:
real 4m28.840s
user 4m1.348s
sys 0m15.816s
...
Example 3: Running 'task-time' on all do_compile buildstats for a
particular build by using shell globbing, sorting on user space CPU
time:
$ task-time tmp/buildstats/20161018083535/*/do_compile --sort user
tmp/buildstats/20161018083535/qemu-native-2.7.0-r1/do_compile:
real 0m49.570s
user 21m45.236s
sys 1m44.380s
tmp/buildstats/20161018083535/linux-yocto-4.8+gitAUTOINC+03bf3dd731_67813e7efa-r0/do_compile:
real 0m49.530s
user 21m39.588s
sys 1m59.576s
tmp/buildstats/20161018083535/gcc-cross-i586-6.2.0-r0/do_compile:
real 1m8.130s
user 15m54.256s
sys 1m28.776s
...
Example 4: Comparing a task between two builds:
$ task-time 201610052{25856,35448}/gettext-0*/do_compile --sort real
20161005235448/gettext-0.16.1-r6/do_compile:
real 0m54.560s
user 0m46.028s
sys 0m2.772s
20161005225856/gettext-0.19.8.1-r0/do_compile:
real 0m41.520s
user 2m17.312s
sys 0m7.536s
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
---
scripts/task-time | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 132 insertions(+)
create mode 100755 scripts/task-time
diff --git a/scripts/task-time b/scripts/task-time
new file mode 100755
index 0000000..e58040a
--- /dev/null
+++ b/scripts/task-time
@@ -0,0 +1,132 @@
+#!/usr/bin/env python3
+
+import argparse
+import os
+import re
+import sys
+
+arg_parser = argparse.ArgumentParser(
+ description="""
+Reports time consumed for one or more task in a format similar to the standard
+Bash 'time' builtin. Optionally sorts tasks by real (wall-clock), user (user
+space CPU), or sys (kernel CPU) time.
+""")
+
+arg_parser.add_argument(
+ "paths",
+ metavar="path",
+ nargs="+",
+ help="""
+A path containing task buildstats. If the path is a directory, e.g.
+build/tmp/buildstats, then all task found (recursively) in it will be
+processed. If the path is a single task buildstat, e.g.
+build/tmp/buildstats/20161018083535/foo-1.0-r0/do_compile, then just that
+buildstat will be processed. Multiple paths can be specified to process all of
+them. Files whose names do not start with "do_" are ignored.
+""")
+
+arg_parser.add_argument(
+ "--sort",
+ choices=("none", "real", "user", "sys"),
+ default="none",
+ help="""
+The measurement to sort the output by. Defaults to 'none', which means to sort
+by the order paths were given on the command line. For other options, tasks are
+sorted in descending order from the highest value.
+""")
+
+args = arg_parser.parse_args()
+
+# Field names and regexes for parsing out their values from buildstat files
+field_regexes = (("elapsed", ".*Elapsed time: ([0-9.]+)"),
+ ("user", "rusage ru_utime: ([0-9.]+)"),
+ ("sys", "rusage ru_stime: ([0-9.]+)"),
+ ("child user", "Child rusage ru_utime: ([0-9.]+)"),
+ ("child sys", "Child rusage ru_stime: ([0-9.]+)"))
+
+# A list of (<path>, <dict>) tuples, where <path> is the path of a do_* task
+# buildstat file and <dict> maps fields from the file to their values
+task_infos = []
+
+def save_times_for_task(path):
+ """Saves information for the buildstat file 'path' in 'task_infos'."""
+
+ if not os.path.basename(path).startswith("do_"):
+ return
+
+ with open(path) as f:
+ fields = {}
+
+ for line in f:
+ for name, regex in field_regexes:
+ match = re.match(regex, line)
+ if match:
+ fields[name] = float(match.group(1))
+ break
+
+ # Check that all expected fields were present
+ for name, regex in field_regexes:
+ if name not in fields:
+ print("Warning: Skipping '{}' because no field matching '{}' could be found"
+ .format(path, regex),
+ file=sys.stderr)
+ return
+
+ task_infos.append((path, fields))
+
+def save_times_for_dir(path):
+ """Runs save_times_for_task() for each file in path and its subdirs, recursively."""
+
+ # Raise an exception for os.walk() errors instead of ignoring them
+ def walk_onerror(e):
+ raise e
+
+ for root, _, files in os.walk(path, onerror=walk_onerror):
+ for fname in files:
+ save_times_for_task(os.path.join(root, fname))
+
+for path in args.paths:
+ if os.path.isfile(path):
+ save_times_for_task(path)
+ else:
+ save_times_for_dir(path)
+
+def elapsed_time(task_info):
+ return task_info[1]["elapsed"]
+
+def tot_user_time(task_info):
+ return task_info[1]["user"] + task_info[1]["child user"]
+
+def tot_sys_time(task_info):
+ return task_info[1]["sys"] + task_info[1]["child sys"]
+
+if args.sort != "none":
+ sort_fn = {"real": elapsed_time, "user": tot_user_time, "sys": tot_sys_time}
+ task_infos.sort(key=sort_fn[args.sort], reverse=True)
+
+first_entry = True
+
+# Catching BrokenPipeError avoids annoying errors when the output is piped into
+# e.g. 'less' or 'head' and not completely read
+try:
+ for task_info in task_infos:
+ real = elapsed_time(task_info)
+ user = tot_user_time(task_info)
+ sys = tot_sys_time(task_info)
+
+ if not first_entry:
+ print()
+ first_entry = False
+
+ # Mimic Bash's 'time' builtin
+ print("{}:\n"
+ "real\t{}m{:.3f}s\n"
+ "user\t{}m{:.3f}s\n"
+ "sys\t{}m{:.3f}s"
+ .format(task_info[0],
+ int(real//60), real%60,
+ int(user//60), user%60,
+ int(sys//60), sys%60))
+
+except BrokenPipeError:
+ pass
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/1] $COREBASE/LICENSE in LIC_FILES_CHKSUM
From: Paul Eggleton @ 2016-10-21 19:36 UTC (permalink / raw)
To: Olaf Mandel; +Cc: openembedded-core
In-Reply-To: <1985222.nRgBkrL9KW@peggleto-mobl.ger.corp.intel.com>
On Fri, 21 Oct 2016 12:29:55 Paul Eggleton wrote:
> For images and other recipes that don't pull in anything by themselves,
> there shouldn't be a need for LIC_FILES_CHKSUM (or indeed LICENSE) to be
> set at all - in order to understand the license for the result the
> appropriate place to look is the license manifest that represents
> everything that goes into the image. In fact, in master / morty, if SRC_URI
> is empty then LIC_FILES_CHKSUM is no longer verified [1].
Actually I will correct that statement to match the code - LIC_FILES_CHKSUM
is no longer *mandatory* if SRC_URI is not set. If it is set, it will still
be checked.
Cheers,
Paul
[1] http://cgit.openembedded.org/openembedded-core/commit/?id=c269547ae8e90a78349f6003385137e4145e145f
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH v2] linux-yocto/4.8: update to v4.8.3
From: Cal Sullivan @ 2016-10-21 23:02 UTC (permalink / raw)
To: Bruce Ashfield, richard.purdie; +Cc: openembedded-core
In-Reply-To: <1477064131-24205-1-git-send-email-bruce.ashfield@windriver.com>
This appears to break preempt-rt.
The meta-series file shows that it dies while patching, and with 32-bit
MACHINEs we get architecture mismatches.
---
Cal
On 10/21/2016 08:35 AM, Bruce Ashfield wrote:
> Integrating the korg -stable release
>
> One commit of note is the fix for CVE-2016-5195 (http://dirtycow.ninja/):
>
> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
>
> The remaining changes are covered by the following shortlog export:
>
> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
> Make __xfs_xattr_put_listen preperly report errors.
> scsi: configure runtime pm before calling device_add in scsi_add_host_with_dma
> v4l: rcar-fcp: Don't force users to check for disabled FCP support
> Linux 4.8.2
> tpm_crb: fix crb_req_canceled behavior
> tpm: fix a race condition in tpm2_unseal_trusted()
> ima: use file_dentry()
> Bluetooth: Add a new 04ca:3011 QCA_ROME device
> ARM: cpuidle: Fix error return code
> ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs
> ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs
> ARM: dts: mvebu: armada-390: add missing compatibility string and bracket
> ARM: fix delays
> x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access
> x86/mm/pkeys: Do not skip PKRU register if debug registers are not used
> arch/x86: Handle non enumerated CPU after physical hotplug
> x86/apic: Get rid of apic_version[] array
> x86/platform/intel-mid: Keep SRAM powered on at boot
> x86/platform/intel-mid: Add Intel Penwell to ID table
> x86/cpu: Rename Merrifield2 to Moorefield
> x86/pkeys: Make protection keys an "eager" feature
> x86/irq: Prevent force migration of irqs which are not in the vector domain
> x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
> arm64: fix dump_backtrace/unwind_frame with NULL tsk
> KVM: PPC: BookE: Fix a sanity check
> KVM: arm/arm64: vgic: Don't flush/sync without a working vgic
> KVM: arm64: Require in-kernel irqchip for PMU support
> KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
> KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
> xen/x86: Update topology map for PV VCPUs
> mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
> mfd: 88pm80x: Double shifting bug in suspend/resume
> mfd: atmel-hlcdc: Do not sleep in atomic context
> mfd: rtsx_usb: Avoid setting ucr->current_sg.status
> ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID
> ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants
> ALSA: ali5451: Fix out-of-bound position reporting
> phy: sun4i-usb: Use spinlock to guard phyctl register access
> usb: dwc3: fix Clear Stall EP command failure
> timekeeping: Fix __ktime_get_fast_ns() regression
> usb: storage: fix runtime pm issue in usb_stor_probe2
> Linux 4.8.1
> ALSA: hda - Add the top speaker pin config for HP Spectre x360
> ALSA: hda - Fix headset mic detection problem for several Dell laptops
> ALSA: hda - Adding one more ALC255 pin definition for headset problem
> Revert "usbtmc: convert to devm_kzalloc"
> USB: serial: cp210x: Add ID for a Juniper console
> usb: usbip: vudc: fix left shift overflow
> Staging: fbtft: Fix bug in fbtft-core
> usb: misc: legousbtower: Fix NULL pointer deference
> Using BUG_ON() as an assert() is _never_ acceptable
> arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP
> Using BUG_ON() as an assert() is _never_ acceptable
>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>
> Josh suggested that I highlight the dirtycow CVE fix, so I've spun a v2
> patch for this update that has much more information.
>
> Bruce
>
> 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 fc1c40caf7b2..00c3d2c7bc1f 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 ?= "b266f7ba78f0cb3d7073e1bf7bd7dfc92bec7431"
> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
> +SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>
> 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"
> +LINUX_VERSION ?= "4.8.3"
>
> 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 41ff5637ec59..799c3f37577d 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"
> +LINUX_VERSION ?= "4.8.3"
>
> KMETA = "kernel-meta"
> KCONF_BSP_AUDIT_LEVEL = "2"
>
> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
> +SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>
> 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 5738f4974b9b..56fbfc7001bf 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 ?= "f46e49344b4c66a6f0917c5a2e9a1d146176519d"
> -SRCREV_machine_qemuarm64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
> -SRCREV_machine_qemumips ?= "5a299402ae58d61429ab091f94748550efe45858"
> -SRCREV_machine_qemuppc ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
> -SRCREV_machine_qemux86 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
> -SRCREV_machine_qemux86-64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
> -SRCREV_machine_qemumips64 ?= "674818dad577cdfc23c6c857aa2b769fc64e379c"
> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
> +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 ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>
> 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"
> +LINUX_VERSION ?= "4.8.3"
>
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
^ permalink raw reply
* Re: [PATCH v2] linux-yocto/4.8: update to v4.8.3
From: Bruce Ashfield @ 2016-10-21 23:20 UTC (permalink / raw)
To: Cal Sullivan, richard.purdie; +Cc: openembedded-core
In-Reply-To: <1c2ea3c5-da69-0b55-c858-a248967a7fcb@intel.com>
On 2016-10-21 7:02 PM, Cal Sullivan wrote:
> This appears to break preempt-rt.
>
Nope. You need the kern-tools patch that I sent earlier this week.
It has nothing to do with this update.
Bruce
> The meta-series file shows that it dies while patching, and with 32-bit
> MACHINEs we get architecture mismatches.
>
> ---
> Cal
>
> On 10/21/2016 08:35 AM, Bruce Ashfield wrote:
>> Integrating the korg -stable release
>>
>> One commit of note is the fix for CVE-2016-5195 (http://dirtycow.ninja/):
>>
>> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
>>
>> The remaining changes are covered by the following shortlog export:
>>
>> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
>> Make __xfs_xattr_put_listen preperly report errors.
>> scsi: configure runtime pm before calling device_add in
>> scsi_add_host_with_dma
>> v4l: rcar-fcp: Don't force users to check for disabled FCP support
>> Linux 4.8.2
>> tpm_crb: fix crb_req_canceled behavior
>> tpm: fix a race condition in tpm2_unseal_trusted()
>> ima: use file_dentry()
>> Bluetooth: Add a new 04ca:3011 QCA_ROME device
>> ARM: cpuidle: Fix error return code
>> ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs
>> ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs
>> ARM: dts: mvebu: armada-390: add missing compatibility string and
>> bracket
>> ARM: fix delays
>> x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack
>> access
>> x86/mm/pkeys: Do not skip PKRU register if debug registers are not
>> used
>> arch/x86: Handle non enumerated CPU after physical hotplug
>> x86/apic: Get rid of apic_version[] array
>> x86/platform/intel-mid: Keep SRAM powered on at boot
>> x86/platform/intel-mid: Add Intel Penwell to ID table
>> x86/cpu: Rename Merrifield2 to Moorefield
>> x86/pkeys: Make protection keys an "eager" feature
>> x86/irq: Prevent force migration of irqs which are not in the
>> vector domain
>> x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
>> arm64: fix dump_backtrace/unwind_frame with NULL tsk
>> KVM: PPC: BookE: Fix a sanity check
>> KVM: arm/arm64: vgic: Don't flush/sync without a working vgic
>> KVM: arm64: Require in-kernel irqchip for PMU support
>> KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
>> KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
>> xen/x86: Update topology map for PV VCPUs
>> mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
>> mfd: 88pm80x: Double shifting bug in suspend/resume
>> mfd: atmel-hlcdc: Do not sleep in atomic context
>> mfd: rtsx_usb: Avoid setting ucr->current_sg.status
>> ALSA: usb-line6: use the same declaration as definition in header
>> for MIDI manufacturer ID
>> ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other
>> variants
>> ALSA: ali5451: Fix out-of-bound position reporting
>> phy: sun4i-usb: Use spinlock to guard phyctl register access
>> usb: dwc3: fix Clear Stall EP command failure
>> timekeeping: Fix __ktime_get_fast_ns() regression
>> usb: storage: fix runtime pm issue in usb_stor_probe2
>> Linux 4.8.1
>> ALSA: hda - Add the top speaker pin config for HP Spectre x360
>> ALSA: hda - Fix headset mic detection problem for several Dell
>> laptops
>> ALSA: hda - Adding one more ALC255 pin definition for headset problem
>> Revert "usbtmc: convert to devm_kzalloc"
>> USB: serial: cp210x: Add ID for a Juniper console
>> usb: usbip: vudc: fix left shift overflow
>> Staging: fbtft: Fix bug in fbtft-core
>> usb: misc: legousbtower: Fix NULL pointer deference
>> Using BUG_ON() as an assert() is _never_ acceptable
>> arm64: debug: avoid resetting stepping state machine when
>> TIF_SINGLESTEP
>> Using BUG_ON() as an assert() is _never_ acceptable
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>
>> Josh suggested that I highlight the dirtycow CVE fix, so I've spun a v2
>> patch for this update that has much more information.
>>
>> Bruce
>>
>> 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 fc1c40caf7b2..00c3d2c7bc1f 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 ?= "b266f7ba78f0cb3d7073e1bf7bd7dfc92bec7431"
>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>> +SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
>> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>> 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"
>> +LINUX_VERSION ?= "4.8.3"
>> 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 41ff5637ec59..799c3f37577d 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"
>> +LINUX_VERSION ?= "4.8.3"
>> KMETA = "kernel-meta"
>> KCONF_BSP_AUDIT_LEVEL = "2"
>> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>> +SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>> 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 5738f4974b9b..56fbfc7001bf 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 ?= "f46e49344b4c66a6f0917c5a2e9a1d146176519d"
>> -SRCREV_machine_qemuarm64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>> -SRCREV_machine_qemumips ?= "5a299402ae58d61429ab091f94748550efe45858"
>> -SRCREV_machine_qemuppc ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>> -SRCREV_machine_qemux86 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>> -SRCREV_machine_qemux86-64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>> -SRCREV_machine_qemumips64 ?= "674818dad577cdfc23c6c857aa2b769fc64e379c"
>> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>> +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 ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>> 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"
>> +LINUX_VERSION ?= "4.8.3"
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>
^ permalink raw reply
* Re: [PATCH v2] linux-yocto/4.8: update to v4.8.3
From: Cal Sullivan @ 2016-10-21 23:40 UTC (permalink / raw)
To: Bruce Ashfield, richard.purdie; +Cc: openembedded-core
In-Reply-To: <2c9d4320-58ac-9af5-9c2b-ff53856c8a93@windriver.com>
On 10/21/2016 04:20 PM, Bruce Ashfield wrote:
> On 2016-10-21 7:02 PM, Cal Sullivan wrote:
>> This appears to break preempt-rt.
>>
>
> Nope. You need the kern-tools patch that I sent earlier this week.
> It has nothing to do with this update.
Oops, didn't see that. I'm using your kernel tools patch as well now and
everything is well. Apologies for the false alarm.
---
Cal
>
> Bruce
>
>> The meta-series file shows that it dies while patching, and with 32-bit
>> MACHINEs we get architecture mismatches.
>>
>> ---
>> Cal
>>
>> On 10/21/2016 08:35 AM, Bruce Ashfield wrote:
>>> Integrating the korg -stable release
>>>
>>> One commit of note is the fix for CVE-2016-5195
>>> (http://dirtycow.ninja/):
>>>
>>> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
>>>
>>> The remaining changes are covered by the following shortlog export:
>>>
>>> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
>>> Make __xfs_xattr_put_listen preperly report errors.
>>> scsi: configure runtime pm before calling device_add in
>>> scsi_add_host_with_dma
>>> v4l: rcar-fcp: Don't force users to check for disabled FCP support
>>> Linux 4.8.2
>>> tpm_crb: fix crb_req_canceled behavior
>>> tpm: fix a race condition in tpm2_unseal_trusted()
>>> ima: use file_dentry()
>>> Bluetooth: Add a new 04ca:3011 QCA_ROME device
>>> ARM: cpuidle: Fix error return code
>>> ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs
>>> ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs
>>> ARM: dts: mvebu: armada-390: add missing compatibility string and
>>> bracket
>>> ARM: fix delays
>>> x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack
>>> access
>>> x86/mm/pkeys: Do not skip PKRU register if debug registers are not
>>> used
>>> arch/x86: Handle non enumerated CPU after physical hotplug
>>> x86/apic: Get rid of apic_version[] array
>>> x86/platform/intel-mid: Keep SRAM powered on at boot
>>> x86/platform/intel-mid: Add Intel Penwell to ID table
>>> x86/cpu: Rename Merrifield2 to Moorefield
>>> x86/pkeys: Make protection keys an "eager" feature
>>> x86/irq: Prevent force migration of irqs which are not in the
>>> vector domain
>>> x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
>>> arm64: fix dump_backtrace/unwind_frame with NULL tsk
>>> KVM: PPC: BookE: Fix a sanity check
>>> KVM: arm/arm64: vgic: Don't flush/sync without a working vgic
>>> KVM: arm64: Require in-kernel irqchip for PMU support
>>> KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
>>> KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
>>> xen/x86: Update topology map for PV VCPUs
>>> mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
>>> mfd: 88pm80x: Double shifting bug in suspend/resume
>>> mfd: atmel-hlcdc: Do not sleep in atomic context
>>> mfd: rtsx_usb: Avoid setting ucr->current_sg.status
>>> ALSA: usb-line6: use the same declaration as definition in header
>>> for MIDI manufacturer ID
>>> ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other
>>> variants
>>> ALSA: ali5451: Fix out-of-bound position reporting
>>> phy: sun4i-usb: Use spinlock to guard phyctl register access
>>> usb: dwc3: fix Clear Stall EP command failure
>>> timekeeping: Fix __ktime_get_fast_ns() regression
>>> usb: storage: fix runtime pm issue in usb_stor_probe2
>>> Linux 4.8.1
>>> ALSA: hda - Add the top speaker pin config for HP Spectre x360
>>> ALSA: hda - Fix headset mic detection problem for several Dell
>>> laptops
>>> ALSA: hda - Adding one more ALC255 pin definition for headset
>>> problem
>>> Revert "usbtmc: convert to devm_kzalloc"
>>> USB: serial: cp210x: Add ID for a Juniper console
>>> usb: usbip: vudc: fix left shift overflow
>>> Staging: fbtft: Fix bug in fbtft-core
>>> usb: misc: legousbtower: Fix NULL pointer deference
>>> Using BUG_ON() as an assert() is _never_ acceptable
>>> arm64: debug: avoid resetting stepping state machine when
>>> TIF_SINGLESTEP
>>> Using BUG_ON() as an assert() is _never_ acceptable
>>>
>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>> ---
>>>
>>> Josh suggested that I highlight the dirtycow CVE fix, so I've spun a v2
>>> patch for this update that has much more information.
>>>
>>> Bruce
>>>
>>> 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 fc1c40caf7b2..00c3d2c7bc1f 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 ?= "b266f7ba78f0cb3d7073e1bf7bd7dfc92bec7431"
>>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>>> +SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
>>> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>>> 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"
>>> +LINUX_VERSION ?= "4.8.3"
>>> 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 41ff5637ec59..799c3f37577d 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"
>>> +LINUX_VERSION ?= "4.8.3"
>>> KMETA = "kernel-meta"
>>> KCONF_BSP_AUDIT_LEVEL = "2"
>>> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>>> +SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>>> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>>> 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 5738f4974b9b..56fbfc7001bf 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 ?= "f46e49344b4c66a6f0917c5a2e9a1d146176519d"
>>> -SRCREV_machine_qemuarm64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>> -SRCREV_machine_qemumips ?= "5a299402ae58d61429ab091f94748550efe45858"
>>> -SRCREV_machine_qemuppc ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>> -SRCREV_machine_qemux86 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>> -SRCREV_machine_qemux86-64 ?=
>>> "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>> -SRCREV_machine_qemumips64 ?=
>>> "674818dad577cdfc23c6c857aa2b769fc64e379c"
>>> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>>> +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 ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>>> 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"
>>> +LINUX_VERSION ?= "4.8.3"
>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v2] linux-yocto/4.8: update to v4.8.3
From: Bruce Ashfield @ 2016-10-21 23:42 UTC (permalink / raw)
To: Cal Sullivan, richard.purdie; +Cc: openembedded-core
In-Reply-To: <20166b2c-d01b-8baf-6f76-ae6ca8c9859c@intel.com>
On 2016-10-21 7:40 PM, Cal Sullivan wrote:
>
>
> On 10/21/2016 04:20 PM, Bruce Ashfield wrote:
>> On 2016-10-21 7:02 PM, Cal Sullivan wrote:
>>> This appears to break preempt-rt.
>>>
>>
>> Nope. You need the kern-tools patch that I sent earlier this week.
>> It has nothing to do with this update.
>
> Oops, didn't see that. I'm using your kernel tools patch as well now and
> everything is well. Apologies for the false alarm.
I wouldn't apologize .. not really a false alarm, I'm glad that it
would have been caught if this did actually do the breakage.
It wasn't obvious that the two would be related .. and it is good that
you mention this, since if this goes into a -rc build, the kern tools
patch must come along as well!
Bruce
>
> ---
> Cal
>
>>
>> Bruce
>>
>>> The meta-series file shows that it dies while patching, and with 32-bit
>>> MACHINEs we get architecture mismatches.
>>>
>>> ---
>>> Cal
>>>
>>> On 10/21/2016 08:35 AM, Bruce Ashfield wrote:
>>>> Integrating the korg -stable release
>>>>
>>>> One commit of note is the fix for CVE-2016-5195
>>>> (http://dirtycow.ninja/):
>>>>
>>>> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
>>>>
>>>> The remaining changes are covered by the following shortlog export:
>>>>
>>>> mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
>>>> Make __xfs_xattr_put_listen preperly report errors.
>>>> scsi: configure runtime pm before calling device_add in
>>>> scsi_add_host_with_dma
>>>> v4l: rcar-fcp: Don't force users to check for disabled FCP support
>>>> Linux 4.8.2
>>>> tpm_crb: fix crb_req_canceled behavior
>>>> tpm: fix a race condition in tpm2_unseal_trusted()
>>>> ima: use file_dentry()
>>>> Bluetooth: Add a new 04ca:3011 QCA_ROME device
>>>> ARM: cpuidle: Fix error return code
>>>> ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs
>>>> ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs
>>>> ARM: dts: mvebu: armada-390: add missing compatibility string and
>>>> bracket
>>>> ARM: fix delays
>>>> x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack
>>>> access
>>>> x86/mm/pkeys: Do not skip PKRU register if debug registers are not
>>>> used
>>>> arch/x86: Handle non enumerated CPU after physical hotplug
>>>> x86/apic: Get rid of apic_version[] array
>>>> x86/platform/intel-mid: Keep SRAM powered on at boot
>>>> x86/platform/intel-mid: Add Intel Penwell to ID table
>>>> x86/cpu: Rename Merrifield2 to Moorefield
>>>> x86/pkeys: Make protection keys an "eager" feature
>>>> x86/irq: Prevent force migration of irqs which are not in the
>>>> vector domain
>>>> x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
>>>> arm64: fix dump_backtrace/unwind_frame with NULL tsk
>>>> KVM: PPC: BookE: Fix a sanity check
>>>> KVM: arm/arm64: vgic: Don't flush/sync without a working vgic
>>>> KVM: arm64: Require in-kernel irqchip for PMU support
>>>> KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
>>>> KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
>>>> xen/x86: Update topology map for PV VCPUs
>>>> mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
>>>> mfd: 88pm80x: Double shifting bug in suspend/resume
>>>> mfd: atmel-hlcdc: Do not sleep in atomic context
>>>> mfd: rtsx_usb: Avoid setting ucr->current_sg.status
>>>> ALSA: usb-line6: use the same declaration as definition in header
>>>> for MIDI manufacturer ID
>>>> ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other
>>>> variants
>>>> ALSA: ali5451: Fix out-of-bound position reporting
>>>> phy: sun4i-usb: Use spinlock to guard phyctl register access
>>>> usb: dwc3: fix Clear Stall EP command failure
>>>> timekeeping: Fix __ktime_get_fast_ns() regression
>>>> usb: storage: fix runtime pm issue in usb_stor_probe2
>>>> Linux 4.8.1
>>>> ALSA: hda - Add the top speaker pin config for HP Spectre x360
>>>> ALSA: hda - Fix headset mic detection problem for several Dell
>>>> laptops
>>>> ALSA: hda - Adding one more ALC255 pin definition for headset
>>>> problem
>>>> Revert "usbtmc: convert to devm_kzalloc"
>>>> USB: serial: cp210x: Add ID for a Juniper console
>>>> usb: usbip: vudc: fix left shift overflow
>>>> Staging: fbtft: Fix bug in fbtft-core
>>>> usb: misc: legousbtower: Fix NULL pointer deference
>>>> Using BUG_ON() as an assert() is _never_ acceptable
>>>> arm64: debug: avoid resetting stepping state machine when
>>>> TIF_SINGLESTEP
>>>> Using BUG_ON() as an assert() is _never_ acceptable
>>>>
>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>>> ---
>>>>
>>>> Josh suggested that I highlight the dirtycow CVE fix, so I've spun a v2
>>>> patch for this update that has much more information.
>>>>
>>>> Bruce
>>>>
>>>> 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 fc1c40caf7b2..00c3d2c7bc1f 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 ?= "b266f7ba78f0cb3d7073e1bf7bd7dfc92bec7431"
>>>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>>>> +SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
>>>> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>>>> 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"
>>>> +LINUX_VERSION ?= "4.8.3"
>>>> 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 41ff5637ec59..799c3f37577d 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"
>>>> +LINUX_VERSION ?= "4.8.3"
>>>> KMETA = "kernel-meta"
>>>> KCONF_BSP_AUDIT_LEVEL = "2"
>>>> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>>>> +SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
>>>> +SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>>>> 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 5738f4974b9b..56fbfc7001bf 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 ?= "f46e49344b4c66a6f0917c5a2e9a1d146176519d"
>>>> -SRCREV_machine_qemuarm64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>>> -SRCREV_machine_qemumips ?= "5a299402ae58d61429ab091f94748550efe45858"
>>>> -SRCREV_machine_qemuppc ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>>> -SRCREV_machine_qemux86 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>>> -SRCREV_machine_qemux86-64 ?=
>>>> "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>>> -SRCREV_machine_qemumips64 ?=
>>>> "674818dad577cdfc23c6c857aa2b769fc64e379c"
>>>> -SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
>>>> -SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
>>>> +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 ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
>>>> 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"
>>>> +LINUX_VERSION ?= "4.8.3"
>>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>>
>>>
>>
>
^ permalink raw reply
* [PATCH 1/2] linux-yocto/4.4: update to v4.4.26
From: Bruce Ashfield @ 2016-10-22 3:47 UTC (permalink / raw)
To: richard.purdie; +Cc: openembedded-core
In-Reply-To: <cover.1477107618.git.bruce.ashfield@windriver.com>
Integrating the 4.4.23->26 -stable releases. Among other fixes
this contains commit:
mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
Which addresses CVE-2016-5195.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 6 +++---
meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 6 +++---
meta/recipes-kernel/linux/linux-yocto_4.4.bb | 20 ++++++++++----------
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
index 33091f1b4ff6..6c1138277e54 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -11,13 +11,13 @@ python () {
raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "6f27f97ed8466b5d7390e8fbb8696c13835a0b1f"
-SRCREV_meta ?= "bbaf01752b0168a63b164978495fad4ead7e8972"
+SRCREV_machine ?= "652b564985db555b549ef73405aea6c38919eefc"
+SRCREV_meta ?= "3030330b066a33ce21164a8b30d0503cf9f68e5b"
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
-LINUX_VERSION ?= "4.4.22"
+LINUX_VERSION ?= "4.4.26"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
index 44ddf21c04b8..76c41639c0d2 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
require recipes-kernel/linux/linux-yocto.inc
-LINUX_VERSION ?= "4.4.22"
+LINUX_VERSION ?= "4.4.26"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_meta ?= "bbaf01752b0168a63b164978495fad4ead7e8972"
+SRCREV_machine ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_meta ?= "3030330b066a33ce21164a8b30d0503cf9f68e5b"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index 41db3f682ae6..e3a3d901d1b2 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86 ?= "standard/base"
KBRANCH_qemux86-64 ?= "standard/base"
KBRANCH_qemumips64 ?= "standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "de294849e02680399a6dd03fedcc03a69e9a6a04"
-SRCREV_machine_qemuarm64 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_qemumips ?= "a41dd187e7d42be65780f25997eb890ead6cc7d9"
-SRCREV_machine_qemuppc ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_qemux86 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_qemux86-64 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_qemumips64 ?= "857685d23d1e8d8a8deb4198b139b95a5bb80825"
-SRCREV_machine ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_meta ?= "bbaf01752b0168a63b164978495fad4ead7e8972"
+SRCREV_machine_qemuarm ?= "187bcc13f3023c3ae0a3ba5c69ae85c4e5e693ac"
+SRCREV_machine_qemuarm64 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_qemumips ?= "2f273556495dd2871f08c73fc3f40d1ad546c638"
+SRCREV_machine_qemuppc ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_qemux86 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_qemux86-64 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_qemumips64 ?= "0a19cacf5738876666a4b530a9fa14f05b355299"
+SRCREV_machine ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_meta ?= "3030330b066a33ce21164a8b30d0503cf9f68e5b"
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
-LINUX_VERSION ?= "4.4.22"
+LINUX_VERSION ?= "4.4.26"
PV = "${LINUX_VERSION}+git${SRCPV}"
--
2.5.0
^ permalink raw reply related
* [PATCH 0/2] linux-yocto: 4.1/4.4 -stable and CVE fixes
From: Bruce Ashfield @ 2016-10-22 3:47 UTC (permalink / raw)
To: richard.purdie; +Cc: openembedded-core
Hi all,
While preparing the 4.8.3 update, and looking more at the dirtycow CVE it
was worthwhile to also speed up the refresh of 4.4 to pick up the -stable
fix for the CVE.
I've also done my own backport of the CVE fix to 4.1 (and will also do an
update when a 4.1 -stable picks up the same change).
I've built and booted both 4.1 and 4.4 to make sure everything is sane,
and I have more builds running for additional coverage.
I'd consider these two commits as candidates for the 2.2 release if there
is another -rc build, they are also safe for backporting to the -stable
branches that have the linux-yocto 4.1 and 4.4 kernels, since these are
not new features and bug/CVE fixes.
Cheers,
Bruce
The following changes since commit 1f75397b7244e989b3cec138e6b2ec0b0eaea42c:
linux-yocto/4.8: update to v4.8.3 (2016-10-21 11:29:30 -0400)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib zedd/kernel
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
Bruce Ashfield (2):
linux-yocto/4.4: update to v4.4.26
linux-yocto/4.1: fix CVE-2016-5195 (dirtycow)
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 6 +++---
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 6 +++---
meta/recipes-kernel/linux/linux-yocto_4.1.bb | 18 +++++++++---------
meta/recipes-kernel/linux/linux-yocto_4.4.bb | 20 ++++++++++----------
6 files changed, 29 insertions(+), 29 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH 2/2] linux-yocto/4.1: fix CVE-2016-5195 (dirtycow)
From: Bruce Ashfield @ 2016-10-22 3:47 UTC (permalink / raw)
To: richard.purdie; +Cc: openembedded-core
In-Reply-To: <cover.1477107618.git.bruce.ashfield@windriver.com>
Backporting commit 19be0eaffa [mm: remove gup_flags FOLL_WRITE games
from __get_user_pages()] to address the dirtycow exploit.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto_4.1.bb | 18 +++++++++---------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index ed7a916be948..b95fb5857725 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -11,8 +11,8 @@ python () {
raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "71daecbcd3f3e8fa73aa036a5539722004e7759c"
-SRCREV_meta ?= "322fa5b2796bfcff7bfbbde1d76c73636ecf5857"
+SRCREV_machine ?= "966ddde490030166010c5770f8f86cdd0e961c76"
+SRCREV_meta ?= "3c3197e65b6f2f5514853c1fe78ae8ffc131b02c"
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 78600427b375..ba01702cb63e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.1.33"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_meta ?= "322fa5b2796bfcff7bfbbde1d76c73636ecf5857"
+SRCREV_machine ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_meta ?= "3c3197e65b6f2f5514853c1fe78ae8ffc131b02c"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index 413234b6d559..788a8eaaa8be 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86 ?= "standard/base"
KBRANCH_qemux86-64 ?= "standard/base"
KBRANCH_qemumips64 ?= "standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "89241b98386f752ab073d3ab5518cb69bacbd97e"
-SRCREV_machine_qemuarm64 ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_machine_qemumips ?= "e00505a0c07a352d1dd57adb8da1768863022979"
-SRCREV_machine_qemuppc ?= "d5ef1ced9d019d20d986e205bddc317961407188"
-SRCREV_machine_qemux86 ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_machine_qemux86-64 ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_machine_qemumips64 ?= "ac476ecd7a56288e3e8ed1ef3872554de661e823"
-SRCREV_machine ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_meta ?= "322fa5b2796bfcff7bfbbde1d76c73636ecf5857"
+SRCREV_machine_qemuarm ?= "d67ef485ce1420df11bda2d9f6fb78ef50c1adff"
+SRCREV_machine_qemuarm64 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_machine_qemumips ?= "65116339cfd210990c9c4710cdfec3ebd59abb0e"
+SRCREV_machine_qemuppc ?= "30816907653b57f1f3d5f9a7a2f6339bab14a680"
+SRCREV_machine_qemux86 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_machine_qemux86-64 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_machine_qemumips64 ?= "f7a0b532b6ac81757d85b0c9a928f45a87c9e364"
+SRCREV_machine ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_meta ?= "3c3197e65b6f2f5514853c1fe78ae8ffc131b02c"
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
--
2.5.0
^ permalink raw reply related
* in what recipe context can "bb" show me TOOLCHAIN_HOST_TASK?
From: Robert P. J. Day @ 2016-10-22 7:39 UTC (permalink / raw)
To: OE Core mailing list
a question about chris larson's nifty "bb" utility ... i recently
figured out that, to get rpm-build into the SDK, i needed to add:
TOOLCHAIN_HOST_TASK += "nativesdk-rpm-build"
to my local.conf. now i'd like to use "bb" to display the full
value of that variable, but i'm not sure what recipe context to use to
do that. as in:
$ bb show -r core-image-minimal TOOLCHAIN_HOST_TASK
Parsing recipes..done.
TOOLCHAIN_HOST_TASK=" nativesdk-rpm-build"
$
that just shows me what i appended. in what environment or recipe
context could i run that command to get the full value of the variable
when the SDK is being built?
rday
p.s. same question if i was using "bitbake -e".
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: in what recipe context can "bb" show me TOOLCHAIN_HOST_TASK?
From: Ulf Magnusson @ 2016-10-22 11:08 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610220333510.8533@localhost.localdomain>
Hello,
On Sat, Oct 22, 2016 at 9:39 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
> a question about chris larson's nifty "bb" utility ... i recently
> figured out that, to get rpm-build into the SDK, i needed to add:
>
> TOOLCHAIN_HOST_TASK += "nativesdk-rpm-build"
>
> to my local.conf. now i'd like to use "bb" to display the full
> value of that variable, but i'm not sure what recipe context to use to
> do that. as in:
>
> $ bb show -r core-image-minimal TOOLCHAIN_HOST_TASK
> Parsing recipes..done.
> TOOLCHAIN_HOST_TASK=" nativesdk-rpm-build"
> $
>
> that just shows me what i appended. in what environment or recipe
> context could i run that command to get the full value of the variable
> when the SDK is being built?
>
> rday
>
> p.s. same question if i was using "bitbake -e".
You're seeing the final value of TOOLCHAIN_HOST_TASK (before any
changes to it within a single task anyway). To extend the default
value instead of replacing it, you would need to do the following
(note the space after the "):
TOOLCHAIN_HOST_TASK_append = " nativesdk-rpm-build"
Below is an explanation of why this works:
Image recipes like core-image-minimal (indirectly) inherit
meta/classes/populate_sdk_base.bbclass, which sets the default value
of TOOLCHAIN_HOST_TASK as follows:
TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host
packagegroup-cross-canadian-${MACHINE}"
Since the global configuration from .conf files like local.conf is
parsed before recipes (and the classes they inherit), using += means
that TOOLCHAIN_HOST_TASK will already have a value by the time the ?=
assignment is encountered, skipping the assignment. With _append, the
appending is delayed until the end of parsing, and the ?= assignment
won't be skipped.
I've submitted many changes to the 2.2 manuals that deal with
conceptual understanding by the way. If you're still reading the 2.1
manuals or earlier, you might want to switch.
* To understand how variable "scopes" work in Yocto, see the note in
http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-viewing-variable-values.
* To understand the motivation behind _append/_prepend/_remove, see
https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages.
* One of the notes in
http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-others
includes a recursive search helper that might be handy.
* Should be documented in the manuals, but currently isn't: To see
which recipes inherit a particular class (either directly or
indirectly), you can use a command like the following one:
$ bitbake-layers show-recipes -i populate_sdk_base
The TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK variables could use
some more documentation. Submitting documentation suggestions to
https://bugzilla.yoctoproject.org/enter_bug.cgi?classification=Documentation
for stuff that's unnecessarily cryptic is highly appreciated.
Cheers,
Ulf
^ permalink raw reply
* Re: in what recipe context can "bb" show me TOOLCHAIN_HOST_TASK?
From: Robert P. J. Day @ 2016-10-22 11:50 UTC (permalink / raw)
To: Ulf Magnusson; +Cc: OE Core mailing list
In-Reply-To: <CAFkk2KTbuq=gTjcWGxOa3FJ-yaQiK6gdAALxxGFhAPNTAL-edQ@mail.gmail.com>
On Sat, 22 Oct 2016, Ulf Magnusson wrote:
> Hello,
>
> On Sat, Oct 22, 2016 at 9:39 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> > a question about chris larson's nifty "bb" utility ... i recently
> > figured out that, to get rpm-build into the SDK, i needed to add:
> >
> > TOOLCHAIN_HOST_TASK += "nativesdk-rpm-build"
> >
> > to my local.conf. now i'd like to use "bb" to display the full
> > value of that variable, but i'm not sure what recipe context to use to
> > do that. as in:
> >
> > $ bb show -r core-image-minimal TOOLCHAIN_HOST_TASK
> > Parsing recipes..done.
> > TOOLCHAIN_HOST_TASK=" nativesdk-rpm-build"
> > $
> >
> > that just shows me what i appended. in what environment or recipe
> > context could i run that command to get the full value of the variable
> > when the SDK is being built?
> >
> > rday
> >
> > p.s. same question if i was using "bitbake -e".
>
> You're seeing the final value of TOOLCHAIN_HOST_TASK (before any
> changes to it within a single task anyway). To extend the default
> value instead of replacing it, you would need to do the following
> (note the space after the "):
>
> TOOLCHAIN_HOST_TASK_append = " nativesdk-rpm-build"
>
> Below is an explanation of why this works:
actually, i just noticed that a few minutes ago. i'm well aware of
the difference in processing between += and _append, it just didn't
occur to me to see if there was a difference at the time. duh.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* basic bitbake commands to create an SDK?
From: Robert P. J. Day @ 2016-10-22 16:05 UTC (permalink / raw)
To: OE Core mailing list
i'm about to dive into SDKs seriously for the first time, so a
shamefully dumb question to make sure i'm starting with the correct
understanding.
starting with up-to-date OE master branch, i selected
MACHINE=mpc8315e-rdb
now, as i see it, i can create just the SDK with either of:
$ bitbake meta-toolchain
$ bitbake -s populate_sdk core-image-minimal
(in that second command, i'm assuming the choice of image is
irrelevant, i just always use core-image-minimal out of habit.)
i'm assuming those commands are entirely equivalent in terms f
generating the SDK, given that meta-toolchain.bb consists solely of:
SUMMARY = "Meta package for building a installable toolchain"
LICENSE = "MIT"
PR = "r7"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
inherit populate_sdk
so the more efficient of those commands would be just
$ bitbake meta-toolchain
also, i did notice the generated host.manifest and target.manifest
files created along with the SDK -- am i correct in assuming those
files represent, respectively, the TOOLCHAIN_HOST_TASK and
TOOLCHAIN_TARGET_TASK values?
anyway, as long as i'm starting with the right info, pretty sure i
can take it from there, accompanied by the SDK manual:
http://www.yoctoproject.org/docs/2.2/sdk-manual/sdk-manual.html
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: basic bitbake commands to create an SDK?
From: Khem Raj @ 2016-10-22 16:37 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610221156210.31588@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]
> On Oct 22, 2016, at 9:05 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>
> i'm about to dive into SDKs seriously for the first time, so a
> shamefully dumb question to make sure i'm starting with the correct
> understanding.
>
> starting with up-to-date OE master branch, i selected
>
> MACHINE=mpc8315e-rdb
>
> now, as i see it, i can create just the SDK with either of:
>
> $ bitbake meta-toolchain
> $ bitbake -s populate_sdk core-image-minimal
>
> (in that second command, i'm assuming the choice of image is
> irrelevant, i just always use core-image-minimal out of habit.)
>
> i'm assuming those commands are entirely equivalent in terms f
> generating the SDK, given that meta-toolchain.bb consists solely of:
>
> SUMMARY = "Meta package for building a installable toolchain"
> LICENSE = "MIT"
>
> PR = "r7"
>
> LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
> file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
> inherit populate_sdk
>
> so the more efficient of those commands would be just
>
> $ bitbake meta-toolchain
>
> also, i did notice the generated host.manifest and target.manifest
> files created along with the SDK -- am i correct in assuming those
> files represent, respectively, the TOOLCHAIN_HOST_TASK and
> TOOLCHAIN_TARGET_TASK values?
>
> anyway, as long as i'm starting with the right info, pretty sure i
> can take it from there, accompanied by the SDK manual:
>
> http://www.yoctoproject.org/docs/2.2/sdk-manual/sdk-manual.html
generally meta-toolchain is prior art. You want to use image specific
SDKs so -cpopulate_sdk <image> is fine. In this case it will include the
needed dev headers/libs in your SDK for that given image automatically
it can be any image
I would recommend to try using eSDK, which can be generated using -cpopulate_sdk_ext
see
https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible_SDK
Thanks
-Khem
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: basic bitbake commands to create an SDK?
From: Robert P. J. Day @ 2016-10-22 16:53 UTC (permalink / raw)
To: Khem Raj; +Cc: OE Core mailing list
In-Reply-To: <68D800E1-2594-4E8B-AB8E-6B9C758FD3CF@gmail.com>
On Sat, 22 Oct 2016, Khem Raj wrote:
> generally meta-toolchain is prior art. You want to use image
> specific SDKs so -cpopulate_sdk <image> is fine. In this case it
> will include the needed dev headers/libs in your SDK for that given
> image automatically it can be any image
ah, good to know, i was starting to get that impression from the
readings. (is there any mention in the docs that meta-toolchain is
deprecated? if that's the correct word.)
> I would recommend to try using eSDK, which can be generated using
> -cpopulate_sdk_ext see
>
> https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible_SDK
i was just perusing the testsdk.bbclass file, where i read at the
top:
# testsdk.bbclass enables testing for SDK and Extensible SDK
#
# For run SDK tests you need to do,
# - bitbake core-image-sato -c populate_sdk
# - bitbake core-image-sato -c testsdk
#
# For run eSDK tests you need to do,
# - bitbake core-image-sato -c populate_sdk_ext
# - bitbake core-image-sato -c testsdkext
does that testing actually require the core-image-sato image? that's
certainly what those comments seem to suggest.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ 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