On Fri, Aug 2, 2019 at 3:58 PM Khem Raj wrote:
> On Fri, Aug 2, 2019 at 5:55 AM Bruce Ashfield
> wrote:
> >
> >
> >
> > On Thu, Aug 1, 2019 at 11:09 PM Khem Raj wrote:
> >>
> >> instead of posting whole shortlog to commit perhaps pointing to ko git
> >> log is going to save us some bits in git
On 8/2/19 4:44 PM, Ross Burton wrote:
This doesn't appear to be used anymore, as saving a few hundred k at the expense
of only using ASCII is quite the compromise in the modern world.
Seconded!
../Randy
Signed-off-by: Ross Burton
---
meta/conf/distro/include/maintainers.inc | 1 -
== Series Details ==
Series: "libxx86misc: remove this now r..." and 8 more
Revision: 1
URL : https://patchwork.openembedded.org/series/19059/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
== Series Details ==
Series: libx11-diet: remove
Revision: 1
URL : https://patchwork.openembedded.org/series/19060/
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 proposed
No modern drivers nor applications use DGA, so remove the client library.
Signed-off-by: Ross Burton
---
meta/conf/distro/include/maintainers.inc | 1 -
.../xorg-lib/libxxf86dga_1.1.5.bb | 19 ---
2 files changed, 20 deletions(-)
delete mode 100644
From: Oleksandr Kravchuk
Signed-off-by: Oleksandr Kravchuk
Signed-off-by: Ross Burton
---
.../0001-Remove-libdir-specification.patch| 468 --
...orgproto_2018.4.bb => xorgproto_2019.1.bb} | 6 +-
2 files changed, 2 insertions(+), 472 deletions(-)
delete mode 100644
DGA (Direct Graphics Access) is an obsolete extension that neither modern X
drivers nor applications support. We'll remove the client library, so remove
the optional dependency on DGA in xdpyinfo.
Signed-off-by: Ross Burton
---
meta/recipes-graphics/xorg-app/xdpyinfo_1.3.2.bb | 2 +-
1 file
Fix the build when the host doesn't have libc.a installed by reverting an
upstream commit, and cherry-pick a build fix from master.
Drop a redundant sed, the expression it removes doesn't exist anymore.
Move most patches to libx11.inc so that they're applied to both libx11 and
libx11-diet.
The generated source file sdksyms.c has a comment with the absolute build path,
which means xserver-xorg-src contains this build path. This is both potential
build information leakage and a source of unreproducibility, so remove the
comment.
Signed-off-by: Ross Burton
---
From: Oleksandr Kravchuk
Signed-off-by: Oleksandr Kravchuk
Signed-off-by: Ross Burton
---
.../{xserver-xorg_1.20.4.bb => xserver-xorg_1.20.5.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.20.4.bb =>
This doesn't appear to be used anymore, as saving a few hundred k at the expense
of only using ASCII is quite the compromise in the modern world.
Signed-off-by: Ross Burton
---
meta/conf/distro/include/maintainers.inc | 1 -
.../xorg-lib/libx11-diet_1.6.8.bb | 16 -
xorgproto is mentioned in the PACKAGECONFIG build dependencies because in the
past it was many separate *proto recipes. Now they're all in one recipe, which
is in DEPENDS, so we don't need to depend on it several times.
Signed-off-by: Ross Burton
---
Ideally we'd disable this as no real world client applications actually use DGA
these days, but some drivers (for example fbdev and cirrus) still need DGA
enabled in the server to build.
Signed-off-by: Ross Burton
---
meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 3 ++-
1 file changed,
The extension this client library is for was removed from the X server over a
decade ago:
commit 22e64108ec63ba9891f8df237913ef9ca731
Author: Daniel Stone
Date: Wed Jul 16 06:25:26 2008 +0300
XFree86: Remove XFree86-Misc extension
Its last remaining purpose in life has been
On Fri, Aug 2, 2019 at 5:55 AM Bruce Ashfield wrote:
>
>
>
> On Thu, Aug 1, 2019 at 11:09 PM Khem Raj wrote:
>>
>> instead of posting whole shortlog to commit perhaps pointing to ko git
>> log is going to save us some bits in git history
>> something like
>>
>>
On Fri, 2 Aug 2019 12:07:33 -0500
Seebs wrote:
> Note that there's no lstat, and no AT_SYMLINK_NOFOLLOW. Which is to
> say, these stats will be following the symlink even though O_NOFOLLOW
> was set. I can probably patch this in a bit.
Followup: Patch applied to master, but also in addition to
On Fri, 2 Aug 2019 11:27:45 -0500
Jason Wessel wrote:
> The sequence of openat() followed by an fstat() on the opened file
> handle, will erase the pseudo uid entry for the symlink, as shown by
> the following lstat() in test 5. The culprit appears to be the
> fstat(), but it could be something
On Fri, 2 Aug 2019 at 18:31, Patchwork
wrote:
>
> * Issue Series does not apply on top of target branch
> [test_series_merge_on_head]
> Suggested fixRebase your series on top of targeted branch
> Targeted branch master (currently at fc634c41e4)
>
This is intended; the patch
It took a while to narrow this down to a concise test case, and I am not
exactly sure what is going on in pseudo. The C app is created based on
mimicking exactly the python code that causes the failure, so that bitbake can
be entirely removed from the picture.
If you use the master branch of
== Series Details ==
Series: meson: add a backported patch to address vala cross-compilation errors
Revision: 1
URL : https://patchwork.openembedded.org/series/19056/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response.
On Fri, 2019-08-02 at 16:53 +0100, Richard Purdie wrote:
> With the patches in master-next and this configuration in local.conf:
>
> BB_HASHSERVE = "localhost:0"
> BB_SIGNATURE_HANDLER = "OEEquivHash"
>
> $ bitbake core-image-sato
> $ bitbake m4-native -c install -f
> $ bitbake core-image-sato
>
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/meson/meson.inc | 1 +
.../meson/meson/vala-cross-compile.patch | 50 +++
2 files changed, 51 insertions(+)
create mode 100644 meta/recipes-devtools/meson/meson/vala-cross-compile.patch
diff --git
Thanks, I have just sent a patch that fixes the error.
Alex
On Thu, 1 Aug 2019 at 16:33, Khem Raj wrote:
> Alexander
>
> Either this or the next patch in this series seems to be causing
>
> https://errors.yoctoproject.org/Errors/Details/256700/
>
> On Tue, Jul 30, 2019 at 8:55 AM Alexander
This has been talked about in a lot of the project meetings but I
wanted to ensure its on the mailing list too.
master-next (and hopefully soon, master) now contain patches which
enable "hash equivalency" support in runqueue in bitbake. That doesn't
sound so interesting until I explain what this
On Fri, 2019-08-02 at 20:33 +0800, chee.yang@intel.com wrote:
> From: Chee Yang Lee
>
> introduce new variable APPENDS to define multiple
> boot configuration for systemd-boot and grub-efi.
>
> APPENDS set the different in kernel option for each .conf
> file(for systemd-boot) or
On Fri, 2019-08-02 at 11:21 +0100, Ross Burton wrote:
> On 02/08/2019 11:24, Robert Yang wrote:
> > There might be processes left after Ctr-C, e.g.:
> > $ rm -f tmp/cache/default-glibc/qemux86/x86_64/
> > $ bitbake -p
> >
> > Press 'Ctrl-C' multiple times during parsing, then bitbake
> >
Upstream bitbake now hanes preserving the unihash data itself, drop
this usage of persist_data which was extremely problematic due to
concurrent task access issues, particulary on loaded systems.
Signed-off-by: Richard Purdie
---
meta/lib/oe/sstatesig.py | 2 --
1 file changed, 2 deletions(-)
Update the metadata to correspond to the bitbake siggen task specification
format change. This standardises on ":" everywhere rather than
the "." delimiter that was being used in some places.
This is an API breaking change but means we now have a consistent format
being used throughout the
Update the code to handle BB_HASHSERV, an autostarted bitbake internal hash
equivalency server suited to local developer usage.
Signed-off-by: Richard Purdie
---
meta/conf/bitbake.conf | 2 +-
meta/lib/oe/sstatesig.py | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git
Bitbake has updated to a cleaned up form of BB_HASHCHECK_FUNCTION,
adapt to this cleanup. This is an API breaking change.
Signed-off-by: Richard Purdie
---
meta/classes/sstate.bbclass | 80 ++---
meta/lib/oe/sstatesig.py| 13 +++---
2 files changed, 45
If the hash server settings are incorrect, show the user useful
error messages instead of tracebacks.
Signed-off-by: Richard Purdie
---
meta/lib/oe/sstatesig.py | 4
1 file changed, 4 insertions(+)
diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index
This code is closely tied with the hash server in bitbake and also means
we can't relibably test the hashserv runqueue functionality without OE
metadata. Moving this to bitbake as a MixIn class makes most sense
and encourages code collaboration and reuse as well as enabling easier
and more
We depend on a number of bitbake API changes, bump the min bitbake
version requirement.
Signed-off-by: Richard Purdie
---
meta/conf/sanity.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/sanity.conf b/meta/conf/sanity.conf
index 45e67525182..92e1886990f 100644
Whilst seemingly a good idea, this exception doesn't really serve any purpose
that bb.fatal() doesn't cover. Wrapping exceptions within exceptions isn't
pythonic.
Its not used in many places, lets clean up those and remove usage of it
entirely. It may ultimately be dropped form bitbake entirely.
> > I've patched our tree so that SRC_URI, LICENSE and CVE_PRODUCT are
> > archived in buildhistory. SRC_URI has many uses and changes and
> > patches can be easily identified. Same with LICENSE, any changes
> > trigger a review. CVE_PRODUCT is exported so that we can do QA check
> > to make sure
On Fri, 2019-08-02 at 07:37 +, mikko.rap...@bmw.de wrote:
> Hi,
>
> On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via
> Openembedded-core wrote:
>
> > I'm interesting in adding SRC_URI support to buildhistory (or a
> > similar mechanism), and would like to get some input.
>
>
> I'd be curious to see the patches.
> It's definitely something we could use here; we used to have nightly
> build checking the build using AUTOREV as well.
>
> On Fri, Aug 2, 2019 at 3:43 AM wrote:
> >
> > Hi,
> >
> > On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via
> >
I'd be curious to see the patches.
It's definitely something we could use here; we used to have nightly
build checking the build using AUTOREV as well.
On Fri, Aug 2, 2019 at 3:43 AM wrote:
>
> Hi,
>
> On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via
> Openembedded-core wrote:
>
On Fri, Aug 02, 2019 at 10:34:35AM +0800, Zang Ruochen wrote:
> -libnss-nis/0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch
> Removed since this is included in 3.1.
>
> Signed-off-by: Zang Ruochen
> ---
> meta/recipes-extended/libnss-nis/libnss-nis.bb | 5 +-
>
On Thu, Aug 1, 2019 at 11:09 PM Khem Raj wrote:
> instead of posting whole shortlog to commit perhaps pointing to ko git
> log is going to save us some bits in git history
> something like
>
>
>
On Fri, 2019-08-02 at 17:12 +0800, liu.min...@gmail.com wrote:
> From: Ming Liu
>
> The results in ${IMGDEPLOYDIR} generated by a image task could be
> used by later image tasks.
No they shouldn't.
> , hence they should be excluded by rm_work. Or else when a image task
> gets rerun but one of
From: Chee Yang Lee
introduce new variable APPENDS to define multiple
boot configuration for systemd-boot and grub-efi.
APPENDS set the different in kernel option for each .conf
file(for systemd-boot) or menuentry(for grub-efi).
Include the differences in the title.
Separate each configuration
== Series Details ==
Series: add variable APPENDS for multiple boot configuration
Revision: 1
URL : https://patchwork.openembedded.org/series/19050/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests
From: Chee Yang Lee
This patch introduce new variable APPENDS to define multiple
boot configuration for systemd-boot and grub-efi.
APPENDS set the different in kernel option for each .conf
file(for systemd-boot) or menuentry(for grub-efi).
Include the differences in the title.
Separate each
ping
--
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
Nanjing, 210012, China
MAIL : zhengrq.f...@cn.fujistu.com
> -Original Message-
> From:
On Fri, Aug 02, 2019 at 11:21:24AM +0100, Ross Burton wrote:
> On 02/08/2019 11:24, Robert Yang wrote:
> > There might be processes left after Ctr-C, e.g.:
> > $ rm -f tmp/cache/default-glibc/qemux86/x86_64/
> > $ bitbake -p
> >
> > Press 'Ctrl-C' multiple times during parsing, then bitbake
On 02/08/2019 11:24, Robert Yang wrote:
There might be processes left after Ctr-C, e.g.:
$ rm -f tmp/cache/default-glibc/qemux86/x86_64/
$ bitbake -p
Press 'Ctrl-C' multiple times during parsing, then bitbake processes may not
exit, and the worse is that we can't start bitbake again, we can't
The following changes since commit fc634c41e4b3fbaf29dc0104ae6b15757e77f60a:
Apache-2.0-with-LLVM-exception: Add new license file (2019-07-31 23:02:56
+0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/kill-bb
There might be processes left after Ctr-C, e.g.:
$ rm -f tmp/cache/default-glibc/qemux86/x86_64/
$ bitbake -p
Press 'Ctrl-C' multiple times during parsing, then bitbake processes may not
exit, and the worse is that we can't start bitbake again, we can't always
reproduce this, but sometime. We can
From: Ming Liu
The changes include:
- Drop all autotools related patches.
- Move weston-launch setuid-install to do_install task since it's not
supported yet by meson build.
- Drop cairo-glesv2 package config, it's not supported by meson build,
the recommended value is hard-coded to
From: Ming Liu
The results in ${IMGDEPLOYDIR} generated by a image task could be used
by later image tasks, hence they should be excluded by rm_work. Or else
when a image task gets rerun but one of its dependent image task does
not, then the results generated by this dependent image task would
Hi,
On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via
Openembedded-core wrote:
> I'm interesting in adding SRC_URI support to buildhistory (or a similar
> mechanism), and would like to get some input.
Yes to this.
Also would be nice if there was an easy way to add bitbake
52 matches
Mail list logo
