> On Oct 26, 2015, at 8:30 AM, Mark Hatle wrote:
>
> Due to problems with the prelinker itself, we need to disable the
> image-prelink by default. This will hopefully be re-enabled in the near
> future.
>
> Signed-off-by: Mark Hatle
> ---
> meta/conf/local.conf.sample | 4 +++-
> 1 file change
I just wanted to update everyone on where we are at. (I won't bore anyone with
any followups past this.)
IA32 (32-bit and 64-bit):
We believe the problems are resolved. The error was a combination of prior
patch merge issues and a bug in glibc 2.22. A patch for the glibc 2.22 has
already been
On Thu, Oct 29, 2015 at 3:19 PM, Logan Buchy wrote:
> Hi guys,
>
> I have a board which has both a Cortex-A9 and a Cortex-m0+, The Cortex-A9
> is running the main application with the Linux kernel while the cortex-m0+
> is present to handle some real-time control tasks.
>
> Currently, I am buildi
> On Oct 29, 2015, at 1:26 PM, Mark Hatle wrote:
>
> On 10/29/15 3:14 PM, Khem Raj wrote:
>> On Thu, Oct 29, 2015 at 1:07 PM, Mark Hatle wrote:
>>> On 10/29/15 10:42 AM, Khem Raj wrote:
Hi All,
I would like to get everyone’s opinion on the libcs we maintain in
OE-Core, as
From: Armin Kuster
This is a is being give a High rating so please consider it for
all 1.1.28 versions.
A type confusion error within the libxslt "xsltStylePreCompute()"
function in preproc.c can lead to a DoS. Confirmed in version 1.1.28,
other versions may also be affected.
Signed-off-by: Arm
On Thu, Oct 29, 2015 at 3:20 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Thu, 2015-10-29 at 13:43 -0700, Juro Bystricky wrote:
> > This patch fixes [YOCTO#8140].
> >
> > The fix consist of allowing 64bit atomic ops for x86.
> > This should be safe for i586 and newer CPUs.
On Thu, 2015-10-29 at 13:43 -0700, Juro Bystricky wrote:
> This patch fixes [YOCTO#8140].
>
> The fix consist of allowing 64bit atomic ops for x86.
> This should be safe for i586 and newer CPUs.
> It also makes the synchronization more efficient.
>
> Signed-off-by: Juro Bystricky
> ---
> .../gl
Hi guys,
I have a board which has both a Cortex-A9 and a Cortex-m0+, The Cortex-A9
is running the main application with the Linux kernel while the cortex-m0+
is present to handle some real-time control tasks.
Currently, I am building the cortex-m0+ firmware separately and saving the
artifacts to
Hi Naresh,
> +OE core ML
>
> On 27 October 2015 at 16:17, Naresh Bhat wrote:
>> Hi Randy,
>>
>> The luvOS project is based on luv-yocto frame work. I have built the
>> luvOS project for AArch64 architecture using qemuarm64.conf machine
>> configuration file and boot the luvOS image on QEMU machi
Thanks for your quick reply.
Yes, the way you propose to apply the patch is cleaner, leaving i386 and i486
unaffected.
However, they do not work already, so I cannot do them any more harm.
Quark does support cmpxchg8b, so in theory it should work. But as you pointed
out,
there are many errata f
EXTRA_OEMAKE is private to OE and shouldn't be exported to
the lsof build.
Signed-off-by: Andre McCurdy
---
meta/recipes-extended/lsof/lsof_4.89.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb
b/meta/recipes-extended/lsof/lsof_4.8
On 10/29/15 3:43 PM, Juro Bystricky wrote:
> This patch fixes [YOCTO#8140].
>
> The fix consist of allowing 64bit atomic ops for x86.
> This should be safe for i586 and newer CPUs.
> It also makes the synchronization more efficient.
I'm not sure this is correct.. see below.
> Signed-off-by: Juro
The base CMAKE__FLAGS are included for all build types,
therefore the CMAKE__FLAGS_RELEASE should contain only
additional flags or over-rides.
https://cmake.org/cmake/help/v3.2/variable/CMAKE_LANG_FLAGS.html
Signed-off-by: Andre McCurdy
---
meta/classes/cmake.bbclass | 10 +-
1 file c
This patch fixes [YOCTO#8140].
The fix consist of allowing 64bit atomic ops for x86.
This should be safe for i586 and newer CPUs.
It also makes the synchronization more efficient.
Signed-off-by: Juro Bystricky
---
.../glibc/glibc/use_64bit_atomics.patch| 24 ++
m
Investigating the bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8140
points to a new bug in glibc that first appeared in 2.21, in particular in
libpthread-2.21.so and is still present in libpthread-2.22.so.
Replacing these libraries with libpthread-2.20.so or libpthread-2.19.so fixes
the
On 10/29/15 3:14 PM, Khem Raj wrote:
> On Thu, Oct 29, 2015 at 1:07 PM, Mark Hatle wrote:
>> On 10/29/15 10:42 AM, Khem Raj wrote:
>>> Hi All,
>>>
>>> I would like to get everyone’s opinion on the libcs we maintain in OE-Core,
>>> as of now, we have
>>>
>>> glibc + cross localedef + kconfig patch
On Thu, Oct 29, 2015 at 1:07 PM, Mark Hatle wrote:
> On 10/29/15 10:42 AM, Khem Raj wrote:
>> Hi All,
>>
>> I would like to get everyone’s opinion on the libcs we maintain in OE-Core,
>> as of now, we have
>>
>> glibc + cross localedef + kconfig patches which are left overs from eglibc
>> days
>
On 10/29/15 10:42 AM, Khem Raj wrote:
> Hi All,
>
> I would like to get everyone’s opinion on the libcs we maintain in OE-Core,
> as of now, we have
>
> glibc + cross localedef + kconfig patches which are left overs from eglibc
> days
I do find the above useful -- include the kconfig part.
>
On Thu, Oct 29, 2015 at 10:28 AM, Dan McGregor
wrote:
> On 29 October 2015 at 10:45, Phil Blundell wrote:
>> On Thu, 2015-10-29 at 08:42 -0700, Khem Raj wrote:
>>
>>> I would like to make a proposal for 2.1 release where
>>>
>>> 1. Drop kconfig support in glibc and we become inline with upstream
On 29 October 2015 at 12:27, Paul Eggleton
wrote:
> At this point in the release it's too late for version upgrades unless the
> upgrade fixes a critical issue and applying the patch to fix that issue is
> more
> risky than the upgrade. I should imagine Ross has this queued for master
> when
> th
On 29 October 2015 at 12:37, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:
> Due the memory leak fixes, I think we could consider the backport for
> 2.0.1 after it proves stable in master for some time.
>
Standard practise would be to cherry-pick the leak fixes, unless you can
convin
On 10/29/15 1:32 PM, Khem Raj wrote:
>
>> On Oct 26, 2015, at 9:55 AM, Mark Hatle wrote:
>>
>> On 10/26/15 11:50 AM, Phil Blundell wrote:
>>> On Mon, 2015-10-26 at 11:45 -0500, Mark Hatle wrote:
While some of the modern hashing techniques and such do improve run
-time dynamic
> On Oct 26, 2015, at 9:55 AM, Mark Hatle wrote:
>
> On 10/26/15 11:50 AM, Phil Blundell wrote:
>> On Mon, 2015-10-26 at 11:45 -0500, Mark Hatle wrote:
>>>
>>>
>>> While some of the modern hashing techniques and such do improve run
>>> -time dynamic
>>> link performance, there is still a hit t
On 29 October 2015 at 10:45, Phil Blundell wrote:
> On Thu, 2015-10-29 at 08:42 -0700, Khem Raj wrote:
>
>> I would like to make a proposal for 2.1 release where
>>
>> 1. Drop kconfig support in glibc and we become inline with upstream
>> 2. Move musl support to OE-Core from meta-musl
>> 3. Drop u
+OE core ML
On 27 October 2015 at 16:17, Naresh Bhat wrote:
> Hi Randy,
>
> The luvOS project is based on luv-yocto frame work. I have built the
> luvOS project for AArch64 architecture using qemuarm64.conf machine
> configuration file and boot the luvOS image on QEMU machine (used
> latest QEMU
Probably caused by last linux-yocto changes.
NOTE: recipe linux-yocto-4.1.8+gitAUTOINC+aed9021602_dbe692d91c-r0: task
do_kernel_configcheck: Started
WARNING: [kernel config]: specified values did not make it into the kernel's
final configuration:
Value requested for CONFIG_I2O not in final ".co
On Thu, 2015-10-29 at 08:42 -0700, Khem Raj wrote:
> I would like to make a proposal for 2.1 release where
>
> 1. Drop kconfig support in glibc and we become inline with upstream
> 2. Move musl support to OE-Core from meta-musl
> 3. Drop uclibc or leave it in current broken state, I would like to
Changelog since 2015-10-18 until 2015-10-25. Projects included in this report:
bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://github.com/Angstrom-distr
Hi All,
I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as
of now, we have
glibc + cross localedef + kconfig patches which are left overs from eglibc days
uclibc - which is more of less unmaintained
Its a significant effort to keep forward porting the kconfig changes
[YOCTO # 8134] This test verifies features introduced in bug 8134.
It requires as resources the files from meta-selftest/files/signing:
For 'gpg --gen-key' the used input was:
key: RSA
key-size: 2048
key-valid: 0
realname: testuser
email: testu...@email.com
comment: nocomment
passphrase: test123
[YOCTO #8182] Optional signing sstate archives and signature verification
[YOCTO #8559] Signing sstate archives with custom dir for gpg keys
Signed-off-by: Daniel Istrate
---
meta/lib/oeqa/selftest/signing.py | 49 +++
1 file changed, 49 insertions(+)
diff --
On 2015-09-20 10:01 PM, Kang Kai wrote:
On 2015年09月18日 18:53, Burton, Ross wrote:
On 18 September 2015 at 04:22, mailto:kai.k...@windriver.com>> wrote:
Upgrade bind to 9.10.3 to fix CVE issues.
Sorry, but we just had the M3 build so can you submit this as a patch
to 9.10.2-P4 instead of
TARGET_CPPFLAGS, TARGET_CFLAGS, TARGET_CPPFLAGS and TARGET_LDFLAGS may
differ between MACHINEs. Since they are exported they affect task hashes
even if unused which leads to multiple variants of allarch packages
existing in sstate and bouncing in the sysroot when switching between
MACHINEs.
allarc
On Thu, Oct 29, 2015 at 10:27 AM, Paul Eggleton
wrote:
> On Thursday 29 October 2015 12:47:18 Jens Rehsack wrote:
>> > Am 08.10.2015 um 16:36 schrieb Jens Rehsack :
>> >
>> > This updates libusb1 from 1.0.19 to 1.0.20
>> >
>> > 2015-09-13: v1.0.20
>> > * Add Haiku support
>> > * Fix multiple memor
Hi Jens,
On Thursday 29 October 2015 12:47:18 Jens Rehsack wrote:
> > Am 08.10.2015 um 16:36 schrieb Jens Rehsack :
> >
> > This updates libusb1 from 1.0.19 to 1.0.20
> >
> > 2015-09-13: v1.0.20
> > * Add Haiku support
> > * Fix multiple memory and resource leaks (#16, #52, #76, #81)
> > * Fix p
On Thu, Oct 29, 2015 at 10:50:06AM +, Ahsan, Noor wrote:
> Ed,
>
> Any update on this.
>
>
> I think os.rename should remain there. We should copy the file in build
> folder in rawcopy. Right now we don't copy it but in others we copy things in
> build folder.
>
I'm ok with the patch then
On Tue, Oct 13, 2015 at 5:37 PM, Jens Rehsack wrote:
>
> Fixes that udev always requires PCI or USB, idenpendently from DISTRO_FEATURES
> or PACKAGECONFIG.
>
> Signed-off-by: Jens Rehsack
Acked-by: Otavio Salvador
--
Otavio Salvador O.S. Systems
http://www.ossystem
> Am 13.10.2015 um 22:37 schrieb Jens Rehsack :
>
>
> Fixes that udev always requires PCI or USB, idenpendently from DISTRO_FEATURES
> or PACKAGECONFIG.
>
> Signed-off-by: Jens Rehsack
> ---
> meta/recipes-core/udev/udev.inc | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
> Am 08.10.2015 um 16:36 schrieb Jens Rehsack :
>
> This updates libusb1 from 1.0.19 to 1.0.20
>
> 2015-09-13: v1.0.20
> * Add Haiku support
> * Fix multiple memory and resource leaks (#16, #52, #76, #81)
> * Fix possible deadlock when executing transfer callback
> * New libusb_free_pollfds() AP
Ed,
Any update on this.
I think os.rename should remain there. We should copy the file in build folder
in rawcopy. Right now we don't copy it but in others we copy things in build
folder.
Noor
-Original Message-
From: Ed Bartosh [mailto:ed.bart...@linux.intel.com]
Sent: Tuesday, Oc
Signed-off-by: Martin Jansa
---
...Add-AO_REQUIRE_CAS-to-fix-build-on-ARM-v6.patch | 61 ++
meta/recipes-support/libunwind/libunwind_1.1.bb| 1 +
2 files changed, 62 insertions(+)
create mode 100644
meta/recipes-support/libunwind/libunwind-1.1/Add-AO_REQUIRE_CAS-to-fix-
If mktemp and coreutils have the same priority for the 'mktemp' command,
/bin/mktemp might point to different destinations depending on which package
is installed first.
Raise the priority to 200 in mktemp recipe to avoid such problem.
Signed-off-by: Chen Qi
---
meta/recipes-extended/mktemp/mkt
The following changes since commit f787b688f2884ce3fa888b4041030538c7d2bf55:
oeqa/utils/decorators: fix missing keyword arguments on decorators
(2015-10-27 07:22:22 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/mktemp-coreutils
On 2015年10月16日 14:28, kai.k...@windriver.com wrote:
From: Kai Kang
The following changes since commit e35c404537db0b46047fcb2ee7d3645e3e0935c5:
bitbake: toaster: Don't descend into directories for cached_layers
(2015-10-11 08:12:58 +0100)
are available in the git repository at:
git://
This patch make `uname -p' and `uname -i' not reporting 'unknown'.
It refers a to Fedora's way to do this.
The coreutils upstream rejects to accept this patch, blaming the
'unknown' result to the kernel not providing enough information.
As on normal distros, `uname -p' and `uname -i' do not report
The following changes since commit f787b688f2884ce3fa888b4041030538c7d2bf55:
oeqa/utils/decorators: fix missing keyword arguments on decorators
(2015-10-27 07:22:22 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/coreutils-uname
On Thu, 2015-10-29 at 07:31 +, Burton, Ross wrote:
> On 28 October 2015 at 10:26, Jens Rehsack wrote:
> Since it's two weeks ago since submitted and this patch series
> fixes several problems how yocto deals with perl module
> distributions, I'd like to get a more concr
On 28 October 2015 at 10:26, Jens Rehsack wrote:
> Since it's two weeks ago since submitted and this patch series fixes
> several problems how yocto deals with perl module distributions, I'd like
> to get a more concrete explanation why an infrastructure fix isn't
> validated during feature freez
48 matches
Mail list logo
