== Series Details ==
Series: libsdl2: Upgrade 2.0.7 -> 2.0.8
Revision: 1
URL : https://patchwork.openembedded.org/series/11225/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the
License checksum changed due to copyright year changes see commit
https://github.com/SDL-mirror/SDL/commit/a9072159b2afff5a338804781312067f0a174c3c#diff-21c55fa400e4d25aed3a755371e32151
Signed-off-by: Khem Raj
---
.../recipes-graphics/libsdl2/{libsdl2_2.0.7.bb => libsdl2_2.0.8.bb} | 6 +++---
1
On Sat, Mar 3, 2018 at 2:45 PM, Otavio Salvador
wrote:
> On Sat, Mar 3, 2018 at 4:59 PM, Khem Raj wrote:
>> On Sat, Mar 3, 2018 at 9:44 AM, Matt Madison wrote:
>>> Since it looks like I'll have to do a v5 on my series anyway, I can
>>> pull in that backport for the aarch64 issue.
>>
>> sure, I
The dtc is used when generating images which use Device Tree and we
must use the OE version to avoid relying on the host one.
Reported-by: Renato Caldas
Signed-off-by: Otavio Salvador
---
Changes in v5:
- rebase on top of master
Changes in v4:
- just rdepends on dtc; it is not used during mkim
On Sat, Mar 3, 2018 at 4:59 PM, Khem Raj wrote:
> On Sat, Mar 3, 2018 at 9:44 AM, Matt Madison wrote:
>> Since it looks like I'll have to do a v5 on my series anyway, I can
>> pull in that backport for the aarch64 issue.
>
> sure, I would suggest we keep 1.9 around as well.
I am against. Go is
I have a recipe which uses both base64 from coreutils-native and hexdump
from util-linux-native so I've put both in my recipe DEPENDS.
Unfortunately do_prepare_sysroot is failing with:
Exception: FileExistsError: [Errno 17] File exists:
'/home/mac/src/oe2/build-bcm7425/tmp-glibc/sysroots-compone
For arm we enforce ARM mode regardless of ARM_INSTRUCTION_SET
choice from config metadata, glibc works fine with thumb2 for
armv7+ so limit the restriction to armv5 and lower, tested on
rpi3 works equally well as arm mode glibc and sheds about 0.5MB
in size for main package alone. Other glibc build
On Sat, Mar 3, 2018 at 9:44 AM, Matt Madison wrote:
> On Sat, Mar 3, 2018 at 8:40 AM, Khem Raj wrote:
>>
>>
>> On 3/2/18 12:33 PM, Matt Madison wrote:
>>>
>>> New in v4:
>>> * updated the go source patch to protect
>>>GOROOT to defer generating an error
>>>until a build actio
On Sat, 2018-03-03 at 09:00 +, Richard Purdie wrote:
> Hi,
>
> I need some help with a problem we keep seeing:
>
> https://autobuilder.yocto.io/builders/nightly-arm64/builds/798
>
> Basically, now and again, for reasons we don't understand, all the
> sanity tests fail for qemuarm64.
Another
On Sat, Mar 3, 2018 at 8:40 AM, Khem Raj wrote:
>
>
> On 3/2/18 12:33 PM, Matt Madison wrote:
>>
>> New in v4:
>> * updated the go source patch to protect
>>GOROOT to defer generating an error
>>until a build action would try to update
>>something in GOROOT
>> * u
On Sat, Mar 3, 2018 at 8:53 AM, Richard Purdie
wrote:
> On Fri, 2018-03-02 at 12:33 -0800, Matt Madison wrote:
>> New in v4:
>> * updated the go source patch to protect
>> GOROOT to defer generating an error
>> until a build action would try to update
>> something in GOROOT
>
Handling of backfilling is trickier than you'd think. We need this to execute
early enough that the user will see the changes in bitbake -e and other output
yet late enough that the virtclass extensions have changed the tunes before
it executes.
It makes more sense to execute this at anonymous pyt
Now bitbake is executing anonymous python fragments in bitbake -e,
ensure we don't show the error in that context (where PN would be
unchanged from default).
Signed-off-by: Richard Purdie
---
meta/classes/base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/class
Now we're filtering tasks in the rpm indexing code so that tasks can only
see the packages they really depend upon, having noexec package_write tasks
around is causing problems since the tasks exist but don't have manifests.
Removing the tasks entirely solves this problem and streamlines the
task
== Series Details ==
Series: "go: Fix for panic: branch too ..." and 1 more
Revision: 1
URL : https://patchwork.openembedded.org/series/11219/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
On Fri, 2018-03-02 at 12:33 -0800, Matt Madison wrote:
> New in v4:
> * updated the go source patch to protect
> GOROOT to defer generating an error
> until a build action would try to update
> something in GOROOT
> * updated go.bbclass to compile for both
> static a
On 3/2/18 12:33 PM, Matt Madison wrote:
New in v4:
* updated the go source patch to protect
GOROOT to defer generating an error
until a build action would try to update
something in GOROOT
* updated go.bbclass to compile for both
static and dynamic linking,
Many go packages can take advantage of dep tool since
they manage their own dependencies, this class helps
in using go dep tool for such packages
Signed-off-by: Khem Raj
---
meta/classes/godep.bbclass | 8
1 file changed, 8 insertions(+)
create mode 100644 meta/classes/godep.bbclass
d
see https://github.com/golang/go/issues/23889
Signed-off-by: Khem Raj
---
meta/recipes-devtools/go/go-1.10.inc | 1 +
.../arm64-fix-branch-too-far-with-TBZ.patch| 50 ++
2 files changed, 51 insertions(+)
create mode 100644
meta/recipes-devtools/go/go-
On Sat, 2018-03-03 at 12:46 -0300, Otavio Salvador wrote:
> On Fri, Mar 2, 2018 at 5:27 PM, Jason Wessel com> wrote:
> >
> > If you install an image into another image (this is the case for
> > custom initrd for example), it will fail with a non obvious python
> > backtrace. This patch modifies
On Fri, Mar 2, 2018 at 5:27 PM, Jason Wessel wrote:
> If you install an image into another image (this is the case for
> custom initrd for example), it will fail with a non obvious python
> backtrace. This patch modifies the package_manager.py print which
> package causes the failure for the futu
On 03/03/18 10:51, Ian Arkver wrote:
On 03/03/18 09:00, Richard Purdie wrote:
Hi,
I need some help with a problem we keep seeing:
https://autobuilder.yocto.io/builders/nightly-arm64/builds/798
Basically, now and again, for reasons we don't understand, all the
sanity tests fail for qemuarm64.
On Sat, 2018-03-03 at 10:51 +, Ian Arkver wrote:
> On 03/03/18 09:00, Richard Purdie wrote:
> > I need some help with a problem we keep seeing:
> >
> > https://autobuilder.yocto.io/builders/nightly-arm64/builds/798
> >
> > Basically, now and again, for reasons we don't understand, all the
> >
On 03/03/18 09:00, Richard Purdie wrote:
Hi,
I need some help with a problem we keep seeing:
https://autobuilder.yocto.io/builders/nightly-arm64/builds/798
Basically, now and again, for reasons we don't understand, all the
sanity tests fail for qemuarm64.
I've poked at this a bit and if I go
Hi,
I need some help with a problem we keep seeing:
https://autobuilder.yocto.io/builders/nightly-arm64/builds/798
Basically, now and again, for reasons we don't understand, all the
sanity tests fail for qemuarm64.
I've poked at this a bit and if I go in onto the failed machine and run
this aga
On Fri, 2018-03-02 at 17:32 +0200, Alexander Kanavin wrote:
> While the upstream just runs a number of make tasks hardcoded to a
> single thread
> in succession, we can add '-j n_threads' to a few of them. The
> benefit
> is real: on my machine the do_compile() time goes from 250 seconds to
> about
26 matches
Mail list logo
