> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
> Sent: den 10 februari 2019 02:29
> To: Richard Purdie ; Khem Raj
> ; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 7 februari 2019 10:01
> To: Khem Raj ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] glibc-locale: Rewri
> -Original Message-
> From: Khem Raj
> Sent: den 8 februari 2019 16:21
> To: Peter Kjellerstedt
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using
> install utility instead of cp
>
> On Fri, Feb 8, 2019 at 12:44 AM Pete
On Sun, Jan 27, 2019 at 9:25 PM Andreas Müller wrote:
>
> Latest LxQt requires recent version of menu-cache.
>
> Signed-off-by: Andreas Müller
Ping
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded
On Sat, 9 Feb 2019 at 19:55, Diego Santa Cruz via Openembedded-core
wrote:
> I am having problems with daemons that get started from the rpm postinstall
> scriptlet, via update-rc.d, that they cannot be killed. Investigating I
> discovered that they have most signals blocked. My guess is that rp
when building with opkg backend and huge packages e.g. chromium/llvm all
going in parallel, memory pressure causes xz to catapult with
do_package_write_ipk: Failed to create package, opkg-build failed with: xz:
(stdin): Cannot allocate memory
since there are many tasks going on in parallel, xz a
Hi there,
I am having problems with daemons that get started from the rpm postinstall
scriptlet, via update-rc.d, that they cannot be killed. Investigating I
discovered that they have most signals blocked. My guess is that rpm blocks
almost all signals so that scriptlets do not fail, but as the
From: Bruce Ashfield
Adding both the required toolchain options (libgcc) and baseline
BSP definitions for arc support.
Author: Alexey Brodkin
Date: Fri Feb 8 18:32:21 2019 +0300
linux-yocto: Add dependency on libgcc for ARC
As of now in case of ARC there's no in-kernel implement
From: Alexey Brodkin
As of now in case of ARC there's no in-kernel implementation of basic libgcc
functions used for millicode, multiplication, division etc instead we simply
link with libgcc.a which provides everything used by the compiler.
Signed-off-by: Alexey Brodkin
Signed-off-by: Bruce As
From: Bruce Ashfield
boot/main: don't check console device file on fs when booting with
initrd/initramfs
In case of initrd/initramfs /dev/console might not exist that early
as devtmpfs is mounted a bit later by /init process so disable this
check in that case.
Signed-off-by:
From: Bruce Ashfield
Hi all,
Sending out my queued patches for linux-yocto. These are mostly for ARC
support, but there are also -stable updates pushed for 4.4/4.9 if anyone
is using those kernels. SRCREV patches for maintained branches will follow
for those changes.
Cheers,
Bruce
The followi
On Fri, Feb 8, 2019 at 7:27 PM Andre McCurdy wrote:
>
> On Fri, Feb 8, 2019 at 5:29 PM Khem Raj wrote:
> >
> > when building with opkg backend and huge packages e.g. chromium/llvm all
> > going in parallel, memory pressure causes xz to catapult with
> >
> > do_package_write_ipk: Failed to create
dump ld.bfd generated .so and see if this symbol is present
On Sat, Feb 9, 2019 at 5:20 AM Martin Jansa wrote:
>
> On Sat, Feb 09, 2019 at 11:06:47AM +0100, Alexander Kanavin wrote:
> > On Sat, 9 Feb 2019 at 10:44, Martin Jansa wrote:
> > > Does it need to depend on mesa directly instead of one
On Sat, 9 Feb 2019 at 18:10, Martin Jansa wrote:
>
> It was sent to upstream (somewhere) by the original author, I haven't found
> it on gitlab, so I've asked original author in:
> https://bugs.gentoo.org/571124#c5
Maybe a new merge request is the quickest way to sort this. The patch
was probabl
It was sent to upstream (somewhere) by the original author, I haven't found
it on gitlab, so I've asked original author in:
https://bugs.gentoo.org/571124#c5
Plain poky probably doesn't use gold, that's why you're not seeing it there.
On Sat, Feb 9, 2019 at 5:43 PM Alexander Kanavin
wrote:
> On
On Sat, 9 Feb 2019 at 14:19, Martin Jansa wrote:
> The fix from
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/qemu&id=c29d4ccfe0a5f53c49883e55c2c2bb444997b1cf
> is still applicable and fixes this.
Somehow the issue does not show up in plain poky, but the fix seems
right.
rubygems 2.7.6 which is in ruby 2.5.3 has this fix and as currently
applied all gem extraction fails as the realpath check is done against
the full path including the file to be extracted which will always fail
as the file hasnt been extracted yet
Signed-off-by: Brett Grandbois
---
.../ruby/ruby
On Sat, Feb 09, 2019 at 11:06:47AM +0100, Alexander Kanavin wrote:
> On Sat, 9 Feb 2019 at 10:44, Martin Jansa wrote:
> > Does it need to depend on mesa directly instead of one of virtual/*
> > providers?
> >
> > It fails to build for targets which use different mesa, e.g. mesa-gl:
> >
> > ERROR:
On Sat, 9 Feb 2019 at 10:44, Martin Jansa wrote:
> Does it need to depend on mesa directly instead of one of virtual/*
> providers?
>
> It fails to build for targets which use different mesa, e.g. mesa-gl:
>
> ERROR: Nothing PROVIDES 'mesa' (but
> /OE/build/luneos-master/webos-ports/openembedded-
On Sat, 9 Feb 2019 at 10:32, Martin Jansa wrote:
> Does enabling virglrenderer and glx do anything useful without any UI?
> If not then I guess it should be enabled directly here or all 3 enabled
> only in the poky's local.conf.
Yes, absolutely. You can instruct qemu to render to an off-screen
b
On Fri, Feb 08, 2019 at 03:45:42PM +0100, Alexander Kanavin wrote:
> This component enables hardware-accelerated GL inside QEMU guests.
> For more information, see here:
>
> https://lwn.net/Articles/767970/
> https://www.collabora.com/news-and-blog/blog/2018/02/12/virtualizing-gpu-access/
> https:
On Sat, Feb 09, 2019 at 12:32:13AM +0100, Alexander Kanavin wrote:
> On Sat, 9 Feb 2019 at 00:12, Martin Jansa wrote:
> > > "
> > > -PACKAGECONFIG_class-native ??= "fdt alsa kvm"
> > > -PACKAGECONFIG_class-nativesdk ??= "fdt sdl kvm"
> > > +PACKAGECONFIG_class-native ??= "fdt alsa kvm virglrender
22 matches
Mail list logo
