Hi Philip,
It was been merged in master, need to backport to Thud
https://github.com/openembedded/openembedded-core/commit/084f4de4dbaf9821516fc0254d35f4fb04311d27#diff-088b9c270c04d657c74b182de1f8e9f6
Thanks,
Manju
-Original Message-
From: Philip Balister [mailto:phi...@balister.org]
Now that docbook-xml and docbook-xsl use the xmlcatalog class, xmlto can stop
shipping a hand-coded catalogue.
It still needs to keep the wrapper so that the sysroot catalog is used instead
of /etc/xml/catalog. The wrapper is native-specific so mark it as such.
Note that this does effectively
The XML catalogue is now at the canonical path, ${sysconfdir}/xml/catalog.
Signed-off-by: Ross Burton
---
meta/recipes-gnome/gtk+/gtk+.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
index
Now that docbook-xml and docbook-xsl are writing catalog files, tell
xmllint/xsltproc where the catalog is.
Signed-off-by: Ross Burton
---
meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Because of differences in how RDEPENDS works for native/target, add libxml2 and
libxslt to RDEPENDS (so that native dependencies work), but also add
libxml2-utils (for xmllint) and libxslt-bin (for xsltproc) to target RDEPENDS.
Also add libxml2-native to DEPENDS as that is needed for the
The XML catalogue is now at the canonical path, ${sysconfdir}/xml/catalog.
Signed-off-by: Ross Burton
---
meta/recipes-support/libxslt/libxslt_1.1.33.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/libxslt/libxslt_1.1.33.bb
Tidy up the install task and don't version the directory under ${docdir}.
Signed-off-by: Ross Burton
---
.../recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
There is no need to ship a static catalog that we have to patch, as upstream
comes with a catalog fragment.
Use the xmlcatalog class to register this catalog.
Signed-off-by: Ross Burton
---
.../docbook-xsl-stylesheets/docbook-xsl.xml | 6 --
Instead of shipping a static catalog and patching it for native builds, use
libxml2-native to generate a catalog with the correct paths.
Use the xmlcatalog class to register this catalog automatically.
Signed-off-by: Ross Burton
---
.../docbook-xml/docbook-xml-dtd4/docbook-xml.xml | 68
This is a new class to handle recipes that need to add/remove entries in the XML
Catalog(ue)[1]. In the future it will handle updating the catalogue on the
target, but the immediate requirement is during the build so currently this only
works with native recipes.
Note that as this is a new class
Signed-off-by: Jonathan Rajotte
---
.../packagegroups/packagegroup-core-tools-profile.bb | 1 -
meta/recipes-devtools/gdb/gdb-common.inc | 1 -
meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb | 1 -
3 files changed, 3 deletions(-)
diff --git
Signed-off-by: Jonathan Rajotte
---
.../packagegroups/packagegroup-core-tools-profile.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index
Multiple patches are to be applied to improve the current ptest suite.
0001-Fix-tests-link-libpause_consumer-on-liblttng-ctl.patch
0002-Fix-test-skip-test_getcpu_override-on-single-thread-.patch
0003-Fix-test-unit-the-tree-origin-can-be-a-symlink-itsel.patch
musl implementation for _SC_NPROCESSORS_CONF is a bit fishy.
[1] https://www.openwall.com/lists/musl/2019/03/15/5
Anyway, we implemented a fallback.
This patch should be gone by next recipe update.
Signed-off-by: Jonathan Rajotte
---
...nd-broken-_SC_NPROCESSORS_CONF-on-MU.patch | 109
Hello,
I noticed there are 3 kernels in Warrior. 4.18, 4.19 an 5.0. Do we
really need 4.18?
I see its the default version for poky-tiny. 4.18 is EOL but maintained
by Windriver.
regards,
Armin
--
___
Openembedded-core mailing list
Hi,
I'm looking for some users that use the ISO images generated by
Bitbake (IMAGE_FSTYPE live or iso). Anyone out there?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
On Wed, Apr 3, 2019 at 9:36 PM Nathan Rossi wrote:
> On Thu, 4 Apr 2019 at 13:48, Khem Raj wrote:
> >
> > On Wed, Apr 3, 2019 at 8:28 PM Nathan Rossi
> wrote:
> > >
> > > On Thu, 4 Apr 2019 at 03:02, Khem Raj wrote:
> > > >
> > > > On Wed, Apr 3, 2019 at 2:26 AM Bach, Pascal
> wrote:
> > > >
> -Original Message-
> From: Richard Purdie
> Sent: den 3 april 2019 14:48
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups
> exist for package_write_* tasks
>
> On Wed, 2019-04-03 at 14:26
+Upstream-Status: Submitted
[https://github.com/GNOME/cogl/pull/4/commits/be7a7b983952d3f2ce2cbaa7b89f413b92e15066]
That's a GNOME mirror, note how your PR was closed. GNOME is at
gitlab.gnome.org.
Ross
On Tue, 2 Apr 2019 at 10:37, wrote:
>
> From: Changqing Li
>
> fix below compile error
This has been unused in OE-Core since the introduction of recipe specific
sysroots. Its not so useful since it only runs once upon sstate installation,
not per installation per sysroot.
Remove the weird looking comment left behind in pixbufcache too.
Signed-off-by: Richard Purdie
---
On Thu, 4 Apr 2019 at 02:39, Khem Raj wrote:
> Definitely, and I agree that we should put relevant information in
> commits, usually
> the information about side effects if any, links to changelog etc. are
> useful too
> however, we should not enforce a behavior which could result in
> redundancy
Ping.
Any comments here?
Thanks,
On 2019年03月19日 16:44, mingli...@windriver.com wrote:
From: Mingli Yu
When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
|
> Am 03.04.2019 um 19:10 schrieb richard.pur...@linuxfoundation.org:
>
> On Wed, 2019-04-03 at 19:05 +0200, Jens Rehsack wrote:
>>
>>
>>> Am 03.04.2019 um 15:58 schrieb Richard Purdie <
>>> richard.pur...@linuxfoundation.org>:
>>>
>>> On Wed, 2019-04-03 at 15:18 +0200, Jens Rehsack wrote:
Current manualexecution required pressing enter button to show each step
information, where this was wasting execution time. Enable display
full steps without needing to any press enter button.
Signed-off-by: Mazliana
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/manualexecution.py |
Simplify and removed unnecessary codes.
Refactor to allow pythonic loop.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/manualexecution.py | 56 +++
1 file changed, 20 insertions(+), 36 deletions(-)
diff --git a/scripts/lib/resulttool/manualexecution.py
Current input checking does not match the standard input practiced
by QA team. Change the input checking to match the standard
input practiced by the QA team.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/manualexecution.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Currently the manual execution display step by sorting
the step as string, where steps were not being sorted
correctly when there are more than 9 steps.
Fixed the step sorting by sorting step as integer.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/manualexecution.py | 2 +-
1 file
These series of patches include enhancement and fixes for manualexecution:
- Enhance input check to standardize checking
- Enhancement to display full steps without press enter
- Fix test steps display order
- Refactor to simplify code and align to pythonic style
Yeoh Ee Peng (4):
When enable DEBUG_BUILD, the perf build failed by the following error:
libbpf.c:727:36: error: 'data' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
This is ok until Khem commit a patch in oe-core:
16643b03227466e2c80a24c2d079fe36e89553c1
This commit import "-Og"
On Thu, 4 Apr 2019 at 07:56, Ovidiu Panait wrote:
> > Have all of these been resolved in master?
> >
> > Ross
>
> No, these have not been resolved in master. Ghostscript version on
> master is 9.26 and the fixes come from 9.27, which hasn't been released yet.
>
> I only sent them for thud since I
On 2019年04月04日 16:02, Burton, Ross wrote:
Some further context (note to self: don't reply to mails during
breakfast): the problem which lead to xmllint failing also leads to
the XSL stylesheets in the sysroot not being used, so xsltproc
downloads them. On my machine, asciidoc should execute
On Thu, Apr 04, 2019 at 10:06:44AM +0800, Changqing Li wrote:
>...
> And also upstream have use same way to fix under
> cogl/driver/gl/gl/cogl-driver-gl.c
>
> https://gitlab.gnome.org/GNOME/cogl/commit/ca5226513eb64bceb38ca01994799c4e7cd9f5fa
Have they?
This looks like a 4 year old commit that
Some further context (note to self: don't reply to mails during
breakfast): the problem which lead to xmllint failing also leads to
the XSL stylesheets in the sysroot not being used, so xsltproc
downloads them. On my machine, asciidoc should execute do_compile in
about a second, but with the
On Wed, Apr 03, 2019 at 01:48:04PM -0700, Andre McCurdy wrote:
>...
> If we let the user pass an arbitrary string to -march then we lose the
> ability to determine that (for example) it's safe for a
> "armv7athf-vfpv3" machine to pull from a "armv7athf-vfpv3d16" package
> feed.
For ARM <= v7 this
From: Kai Kang
When gcc compile options '-O2 -fvisibility=default' are applied, it
fails to compile virglrenderer for x86:
| ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
R_386_GOTOFF against undefined symbol `util_cpu_caps' can not be used
when making a shared object
I've submitted fixes for this already.
Ross
On Thu, 4 Apr 2019 at 07:12, wrote:
>
> From: Mingli Yu
>
> asciidoc-native build with below error when
> there is no xmllint program located on build
> host:
> | python3 a2x.py -f manpage doc/asciidoc.1.txt
> | a2x: ERROR: "xmllint" --nonet --noout
On 03.04.2019 16:34, Burton, Ross wrote:
Have all of these been resolved in master?
Ross
No, these have not been resolved in master. Ghostscript version on
master is 9.26 and the fixes come from 9.27, which hasn't been released yet.
I only sent them for thud since I remember that on
From: Mingli Yu
asciidoc-native build with below error when
there is no xmllint program located on build
host:
| python3 a2x.py -f manpage doc/asciidoc.1.txt
| a2x: ERROR: "xmllint" --nonet --noout --valid
38 matches
Mail list logo
