[OE-core] [oe-core][THUD][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk
Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all nativesdk*
sstate into esdk
Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation
Signed-off-by: Jaewon Lee
---
meta/classes/populate_sdk_ext.bbclass | 28 +++-
meta/lib/oe/copy_buildsystem.py | 8 ++--
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index 40b0375..d98b0e5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
SDK_EXT_TYPE ?= "full"
SDK_INCLUDE_PKGDATA ?= "0"
SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
SDK_RECRDEP_TASKS ?= ""
@@ -401,9 +402,27 @@ python copy_buildsystem () {
excluded_targets = get_sdk_install_targets(d, images_only=True)
sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') +
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+excluded_targets.split(),
+nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+sigfile,
+nativesigfile_pruned,
+sigfile)
+
oe.copy_buildsystem.prune_lockedsigs([],
excluded_targets.split(),
sigfile,
+ False,
lockedsigs_pruned)
sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and
not sdk_include_nativesdk:
# Create the filtered task list used to generate the sstate cache
shipped with the SDK
tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
@@ -658,9 +677,16 @@ fakeroot python do_populate_sdk_ext() {
d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
# ESDKs have a libc from the buildtools so ensure we don't ship linguas
twice
d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
populate_sdk_common(d)
}
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
def get_ext_sdk_depends(d):
# Note: the deps varflag is a list not a string, so we need to specify
expand=False
deps = d.getVarFlag('do_image_complete', 'deps', False)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 7cb784c..5bc728e 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -168,7 +168,7 @@ def generate_locked_sigs(sigfile, d):
tasks = ['%s.%s' % (v[2], v[1]) for v in depd.values()]
bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs,
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative,
pruned_output):
with open(lockedsigs, 'r') as infile:
bb.utils.mkdirhier(os.path.dirname(pruned_output))
with open(pruned_output, 'w') as f:
@@ -178,7 +178,11 @@ def prune_lockedsigs(excluded_tasks, excluded_targets,
lockedsigs, pruned_output
if line.endswith('\\\n'):
splitval = line.strip().split(':')
if not splitval[1] in excluded_tasks and not
splitval[0] in excluded_targets:
-f.write(lin
Re: [OE-core] Link issue of virglrenderer on x86 with gcc options '-O2 -fvisibility=default'
On 2019/4/3 上午12:16, Khem Raj wrote: On Tue, Apr 2, 2019 at 8:46 AM Kang Kai wrote: Hi Raj, I meet a link problem of virglrenderer with gcc options '-O2 -fvisibility=default' configured in local.conf: SELECTED_OPTIMIZATION = "-O2 -fvisibility=default" It fails on qemux86 but succeeds on x86-64. And the error message: | i586-poky-linux-libtool: link: i586-poky-linux-gcc -m32 -march=i586 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror= format-security --sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot -shared -fPIC -DPIC .libs/virglrenderer.o *-Wl,--whole-archive* ./.libs/libvrend.a gallium/auxiliary/.libs/libgallium.a *-Wl,--no-whole-archive* -lm -ldrm -lgbm -lepoxy -lX1 1 -m32 -march=i586 -fstack-protector-strong --sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe- sysroot -O2 -Wl,-Bsymbolic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now -pthread -Wl,-soname -Wl,libvirglrenderer.so.0 -o .libs/libvirglrenderer.so.0.2.0 | /home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/../../libexec/ i586-poky-linux/gcc/i586-poky-linux/8.3.0/ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation R_386_GOTOFF against undefined symbol `ut il_cpu_caps' can not be used when making a shared object It could pass if options -Wl,--whole-archive and -Wl,--no-whole-archive are removed. It says 'relocation R_386_GOTOFF' but when I check the file, it shows relocation type is R_386_GOT32X: $ readelf --relocs ./util/.libs/u_cpu_detect.o | grep util_cpu_caps 0092 102b R_386_GOT32X 0004 util_cpu_caps AFAIK R_386_GOT32X is not used with PIC. But I don't know why the type is R_386_GOT32X that -fPIC has been applied already? Any suggestion is great appreciated. Thanks. it seems you have to build PIC archive for libgallium.a, it might not be using the right -fPIC flags during compile/link phase. Hi Raj, Thanks a lot. It turns out that caused by link option '-Bsymbolic'. Replace with '-Bdynamic' could resolve the issue. And I'll send a patch to upstream. Regards, Kai -- Kai Kang -- Kai Kang -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake: 3.14.0 -> 3.14.1
This patch should also go into warrior as I think we should not ship 3.14.0 due
to the issue mentioned bellow.
> -Original Message-
> From: Pascal Bach
> Sent: Montag, 1. April 2019 14:17
> To: openembedded-core@lists.openembedded.org
> Cc: Bach, Pascal (BT CPS R&D ZG FW CCP)
> Subject: [PATCH] cmake: 3.14.0 -> 3.14.1
>
> The FindFontconfig module added by 3.14.0 accidentally used uppercase
> FONTCONFIG_* variable names that do not match our conventions.
> 3.14.1 revises the module to use Fontconfig_* variable names.
> This is incompatible with 3.14.0 but since the module is new in the
> 3.14 series usage should not yet be widespread.
>
> Signed-off-by: Pascal Bach
> ---
> .../cmake/{cmake-native_3.14.0.bb => cmake-native_3.14.1.bb} | 0
> meta/recipes-devtools/cmake/cmake.inc | 4
> ++--
> meta/recipes-devtools/cmake/{cmake_3.14.0.bb => cmake_3.14.1.bb} | 0
> 3 files changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-
> devtools/cmake/{cmake-native_3.14.0.bb => cmake-native_3.14.1.bb}
> (100%) rename meta/recipes-devtools/cmake/{cmake_3.14.0.bb =>
> cmake_3.14.1.bb} (100%)
>
> diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> b/meta/recipes-devtools/cmake/cmake-native_3.14.1.bb
> similarity index 100%
> rename from meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> rename to meta/recipes-devtools/cmake/cmake-native_3.14.1.bb
> diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-
> devtools/cmake/cmake.inc
> index f787851e2d..5b0bce6808 100644
> --- a/meta/recipes-devtools/cmake/cmake.inc
> +++ b/meta/recipes-devtools/cmake/cmake.inc
> @@ -18,7 +18,7 @@ SRC_URI =
> "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz
> \
>
> file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \ "
>
> -SRC_URI[md5sum] = "7504e4f3e05b59e083f2127e07059d5d"
> -SRC_URI[sha256sum] =
> "aa76ba67b3c2af1946701f847073f4652af5cbd9f141f221c97af99127e75502"
> +SRC_URI[md5sum] = "7efe5394e85c3292ad020b8b70e55669"
> +SRC_URI[sha256sum] =
> "7321be640406338fc12590609c42b0fae7ea12980855c1be363d25dcd76bb25f"
>
> UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
> diff --git a/meta/recipes-devtools/cmake/cmake_3.14.0.bb b/meta/recipes-
> devtools/cmake/cmake_3.14.1.bb
> similarity index 100%
> rename from meta/recipes-devtools/cmake/cmake_3.14.0.bb
> rename to meta/recipes-devtools/cmake/cmake_3.14.1.bb
> --
> 2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/3] cmake-native: Enable ccmake by default and depend on ncurses
>
> Enable the building of the curses based ui for cmake. This depends on
> ncurses.
I think this is acceptable. It might also be useful for people wanting to use
ccmake inside an SDK.
> Signed-off-by: Nathan Rossi
> ---
> This patch suggests enabling this in the cmake-native recipe, however this
> might be undesirable for bootstrapping reasons. Whilst ccmake is not used
> normally the added dependency on ncurses is likely required for other parts
> of the build so impact on build ordering and time should be relatively
> minimal.
>
> Changes in v2:
> - None
> ---
> meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> index fedcf3d4bd..b2952ee5f5 100644
> --- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> +++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> @@ -1,7 +1,7 @@
> require cmake.inc
> inherit native
>
> -DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> curl-native"
> +DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> curl-native ncurses-native"
>
> SRC_URI += "file://OEToolchainConfig.cmake \
> file://environment.d-cmake.sh \ @@ -13,10 +13,9 @@ SRC_URI +=
> "file://OEToolchainConfig.cmake \ B = "${WORKDIR}/build"
> do_configure[cleandirs] = "${B}"
>
> -# Disable ccmake since we don't depend on ncurses CMAKE_EXTRACONF =
> "\
> -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
> --DBUILD_CursesDialog=0 \
> +-DBUILD_CursesDialog=1 \
> -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
> -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
> -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \
> ---
> 2.20.1
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Git commit process question.
On Tue, Apr 02, 2019 at 03:46:14PM -0400, Tom Rini wrote: > On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote: > > On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote: > > > > > > > > > On 4/1/19 4:02 PM, Richard Purdie wrote: > > > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote: > > > >> Hello, > > > >> > > > >> I have noticed a large number of git commits with no header > > > >> information being accepted. > > > > Can you be more specific about what "no header information" means? You > > > > mean a shortlog and no full log message? > > > Commits with just a "subject" and signoff. No additional information > > > > > > We tend to reference back to how the kernel does things. > > > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > > These two sections in particular. > > > > > > > > > 2) Describe your changes > > > > > > Describe your problem. Whether your patch is a one-line bug fix or 5000 > > > lines of a new feature, there must be an underlying problem that > > > motivated you to do this work. Convince the reviewer that there is a > > > problem worth fixing and that it makes sense for them to read past the > > > first paragraph. > > >... > > > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? That would be more trivial than useful. And so far noone has stated any actual problem that would be solved by adding such a new requirement. > Tom cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized
On Wed, Apr 03, 2019 at 10:29:08AM +0800, Changqing Li wrote:
>
> On 4/2/19 7:31 PM, Adrian Bunk wrote:
> > On Tue, Apr 02, 2019 at 05:08:33PM +0800, changqing...@windriver.com wrote:
> > > From: Changqing Li
> > >
> > > fix below compile error with -Werror=maybe-uninitialized
> > >
> > > | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error:
> > > 'gltype' may be used uninitialized in this function
> > > [-Werror=maybe-uninitialized]
> > > | *out_gltype = gltype;
> > > | ^~~~
> > > | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error:
> > > 'glintformat' may be used uninitialized in this function
> > > [-Werror=maybe-uninitialized]
> > > | *out_glintformat = glintformat;
> > > | ~^
> > > ...
> > Looking at the code, is this a failure that only happens with DEBUG_FLAGS?
> Yes, only happen with DEBUG_FLAGS
> > > +--- a/cogl/driver/gl/gles/cogl-driver-gles.c
> > > b/cogl/driver/gl/gles/cogl-driver-gles.c
> > > +@@ -74,9 +74,9 @@ _cogl_driver_pixel_format_to_gl (CoglContext *context,
> > > + GLenum *out_gltype)
> > > + {
> > > + CoglPixelFormat required_format;
> > > +- GLenum glintformat;
> > > ++ GLenum glintformat = 0;
> > > + GLenum glformat = 0;
> > > +- GLenum gltype;
> > > ++ GLenum gltype = 0;
> > > ...
> > Assigning random values to variables is a bug,
> > they do not even seem to be valid values for these variables.
>
> According to code logic, glformat and glintformat will assigned
> simultaneously and usually with same value,
But glformat has an assert later to ensure the 0 doesn't leak anywhere.
> and 0 mean invalid pixel format.
For pixel format 0 means COGL_PIXEL_FORMAT_ANY.
For glintformat I don't know what would happen if 0 is used.
> [snip]
>
> case COGL_PIXEL_FORMAT_DEPTH_24_STENCIL_8:
> glintformat = GL_DEPTH_STENCIL;
> glformat = GL_DEPTH_STENCIL;
> gltype = GL_UNSIGNED_INT_24_8;
> break;
>
> and for gtype, there also should be no problem according to the code logic.
According to the current code.
If some future change breaks the code, it would pass invalid data at
runtime instead of giving a compile warning.
> and the fix is just for eliminate the error when DEBUG_FLAGS is enabled.
Looking at the code, does passing --enable-maintainer-flags=no
to configure work around this gcc bug?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Git commit process question.
On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? Apart from making the commit message longer what does this achieve? The commit already has a timestamp and author. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Git commit process question.
Just to make clear, the AUH workflow does require the maintainer to sign off and edit a commit message via 'git commit -s --reset-author --amend' for every commit, so AUH does not get in the way of useful commit messages. Alex On Wed, 3 Apr 2019 at 12:31, Burton, Ross wrote: > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > The kernel does not have "upgrade foo to the latest upstream version" > > > commits. > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > most of the time there is no specific motivation other than upgrading > > > to the latest upstream version. > > > > But since that's just filling in a template the body can also be a > > template perhaps with useful AUH data (run at ... by ... ?) ? > > Apart from making the commit message longer what does this achieve? > The commit already has a timestamp and author. > > Ross > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2 V2] gobject-introspection: auto-enable/-disable gobject-introspection for meson
On Mon, Apr 1, 2019 at 6:21 PM Alexander Kanavin wrote: > > On Mon, 1 Apr 2019 at 18:10, Alexander Kanavin wrote: > > > Thanks, may I also ask that you go over the recipes in oe-core that > > inherit meson, and tweak them to use this option? (there is not a lot, > > and some don't use g-i at all). > > The exact list is: > > at-spi2-core > libsoup-2.4 > gdk-pixbuf > libmodulemd > atk > pango > libdazzle > json-glib > clutter-gtk-1.0.inc > > Alex Some intermediate info: * adjusted gobject-introspection.bbclass to make flags (true/false or yes/no ...) overridable and removed configure option whitelisting * changed the recipes above * update glib-networking to get gnutls option back With test builds I get: * gstreamer1.0-plugins-good complains for unrecognised 'enable-introspection' and 'disable-introspection'. This is odd for two reasons: Both options enable/disable? gstreamer1.0-plugins-good complains but has introspection.m4 what is the problem? * Some recipes in meta-gnome complain for unrecognised options now To be continued... Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] [oe] Git commit process question.
On 4/3/19 3:38 AM, Alexander Kanavin wrote: > Just to make clear, the AUH workflow does require the maintainer to > sign off and edit a commit message via 'git commit -s --reset-author > --amend' for every commit, Not sure if this a requirement anymore. Most of my packages got updated by other folks this time around. Hard to say if the AUH played a part or are folks now using the devtool check. > so AUH does not get in the way of useful > commit messages. There was talk of using the AUH to fast track updates that pass the process so in that case the message would be whatever the AUH provides - armin > > Alex > > On Wed, 3 Apr 2019 at 12:31, Burton, Ross wrote: >> On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: >> pr The kernel does not have "upgrade foo to the latest upstream version" commits. With the Automatic Upgrade Helper this is a semi-automatic task, and most of the time there is no specific motivation other than upgrading to the latest upstream version. >>> But since that's just filling in a template the body can also be a >>> template perhaps with useful AUH data (run at ... by ... ?) ? >> Apart from making the commit message longer what does this achieve? >> The commit already has a timestamp and author. >> >> Ross >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2 V2] gobject-introspection: auto-enable/-disable gobject-introspection for meson
On Wed, 3 Apr 2019 at 12:55, Andreas Müller wrote: t builds I get: > * gstreamer1.0-plugins-good complains for unrecognised > 'enable-introspection' and 'disable-introspection'. This is odd for > two reasons: Both options enable/disable? gstreamer1.0-plugins-good > complains but has introspection.m4 what is the problem? It seems as though gst-plugins-good does not support introspection, and never did! So you can simply add the option whitelisting to that recipe specifically. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic/engine: Add missing newline
On some hosts the wic.Wic2.test_wic_cp_ext selftest was failing as files weren't
being copied into the rootfs with "wic cp". This was due to a bug added by:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=89d4a8df074598cfb3a76e41db7c45d845afd961
where there should be a second newline added at the end of the expression due
to the difference in the way echo -e and printf behave.
Signed-off-by: Richard Purdie
---
scripts/lib/wic/engine.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index ea600d2854e..ab33fa6042e 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -338,7 +338,7 @@ class Disk:
def copy(self, src, pnum, path):
"""Copy partition image into wic image."""
if self.partitions[pnum].fstype.startswith('ext'):
-cmd = "printf 'cd {}\nwrite {} {}' | {} -w {}".\
+cmd = "printf 'cd {}\nwrite {} {}\n' | {} -w {}".\
format(path, src, os.path.basename(src),
self.debugfs, self._get_part_image(pnum))
else: # fat
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] useradd.bbclass: Make sure users/groups exist for package_write_* tasks
If the populate_lic task and any of the package_write_* tasks need to
run, but the package task can be restored from the sstate cache, then
the fetch task, which is a dependency of populate_lic, will wipe out
the RSS including any users/groups that have been created. This
results in that the package_write_* tasks are run without any
user/group information, which causes them to fallback to either use
the root user for any unknown users/groups (rpm) or to use the numeric
UIDs/GIDs (deb/ipk). Neither solution will yield correct packages.
Signed-off-by: Peter Kjellerstedt
---
meta/classes/useradd.bbclass | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
index 124becd082..e32315a1af 100644
--- a/meta/classes/useradd.bbclass
+++ b/meta/classes/useradd.bbclass
@@ -4,7 +4,7 @@ inherit useradd_base
# target sysroot, and shadow -native and -sysroot provide the utilities
# and support files needed to add and modify user and group accounts
DEPENDS_append_class-target = " base-files shadow-native shadow-sysroot shadow
base-passwd"
-PACKAGE_WRITE_DEPS += "shadow-native"
+PACKAGE_WRITE_DEPS += "shadow-native shadow-sysroot base-passwd"
# This preinstall function can be run in four different contexts:
#
@@ -144,7 +144,10 @@ python useradd_sysroot_sstate () {
task = d.getVar("BB_CURRENTTASK")
if task == "package_setscene":
bb.build.exec_func("useradd_sysroot", d)
-elif task == "prepare_recipe_sysroot":
+elif (task == "prepare_recipe_sysroot" or
+ task == "package_write_deb" or
+ task == "package_write_ipk" or
+ task == "package_write_rpm"):
# Used to update this recipe's own sysroot so the user/groups are
available to do_install
scriptfile =
d.expand("${RECIPE_SYSROOT}${bindir}/postinst-useradd-${PN}")
bb.build.exec_func("useradd_sysroot", d)
@@ -161,13 +164,16 @@ python useradd_sysroot_sstate () {
os.chmod(scriptfile, 0o755)
}
-do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
-SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
SYSROOTFUNC = ""
+SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
-SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
+do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
+do_package_write_deb[prefuncs] += "${SYSROOTFUNC}"
+do_package_write_ipk[prefuncs] += "${SYSROOTFUNC}"
+do_package_write_rpm[prefuncs] += "${SYSROOTFUNC}"
-SSTATEPREINSTFUNCS_append_class-target = " useradd_sysroot_sstate"
+SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
+SSTATEPREINSTFUNCS += "${SYSROOTFUNC}"
do_package_setscene[depends] += "${USERADDSETSCENEDEPS}"
do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}"
--
2.12.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [thud][PATCH] ghostscript: Fix CVE-2019-3835 and CVE-2019-3838
It was found that the superexec operator was available in the internal
dictionary in ghostscript before 9.27. A specially crafted PostScript
file could use this flaw in order to, for example, have access to the
file system outside of the constrains imposed by -dSAFER.
It was found that the forceput operator could be extracted from the
DefineResource method in ghostscript before 9.27. A specially crafted
PostScript file could use this flaw in order to, for example, have
access to the file system outside of the constrains imposed by -dSAFER.
References:
https://nvd.nist.gov/vuln/detail/CVE-2019-3835
https://nvd.nist.gov/vuln/detail/CVE-2019-3838
Upstream patches:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=779664d
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e8acf6d
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2055917
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d683d1e
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ed9fcd9
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a82601e
Signed-off-by: Ovidiu Panait
---
.../ghostscript/CVE-2019-3835-0001.patch | 99 ++
.../ghostscript/CVE-2019-3835-0002.patch | 71 +
.../ghostscript/CVE-2019-3835-0003.patch | 295 ++
.../ghostscript/CVE-2019-3835-0004.patch | 167 ++
.../ghostscript/CVE-2019-3838-0001.patch | 34 ++
.../ghostscript/CVE-2019-3838-0002.patch | 30 ++
.../ghostscript/ghostscript_9.26.bb | 6 +
7 files changed, 702 insertions(+)
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0002.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0003.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0004.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3838-0001.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3838-0002.patch
diff --git
a/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
new file mode 100644
index 00..30ce04a7b1
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
@@ -0,0 +1,99 @@
+From ad3ad6b389653722507e588c5cb34d8731e49e89 Mon Sep 17 00:00:00 2001
+From: Chris Liddell
+Date: Mon, 26 Nov 2018 18:01:25 +
+Subject: [PATCH] Have gs_cet.ps run from gs_init.ps
+
+Previously gs_cet.ps was run on the command line, to set up the interpreter
+state so our output more closely matches the example output for the QL CET
+tests.
+
+Allow a -dCETMODE command line switch, which will cause gs_init.ps to run the
+file directly.
+
+This works better for gpdl as it means the changes are made in the intial
+interpreter state, rather than after initialisation is complete.
+
+This also means adding a definition of the default procedure for black
+generation and under color removal (rather it being defined in-line in
+.setdefaultbgucr
+
+Also, add a check so gs_cet.ps only runs once - if we try to run it a second
+time, we'll just skip over the file, flushing through to the end.
+
+CVE: CVE-2019-3835
+Upstream-Status: Backport [git://git.ghostscript.com/ghostpdl.git]
+
+Signed-off-by: Ovidiu Panait
+---
+ Resource/Init/gs_cet.ps | 11 ++-
+ Resource/Init/gs_init.ps | 13 -
+ 2 files changed, 22 insertions(+), 2 deletions(-)
+
+diff --git a/Resource/Init/gs_cet.ps b/Resource/Init/gs_cet.ps
+index d3e1686..75534bb 100644
+--- a/Resource/Init/gs_cet.ps
b/Resource/Init/gs_cet.ps
+@@ -1,6 +1,11 @@
+ %!PS
+ % Set defaults for Ghostscript to match Adobe CPSI behaviour for CET
+
++systemdict /product get (PhotoPRINT SE 5.0v2) readonly eq
++{
++ (%END GS_CET) .skipeof
++} if
++
+ % do this in the server level so it is persistent across jobs
+ //true 0 startjob not {
+ (*** Warning: CET startup is not in server default) = flush
+@@ -25,7 +30,9 @@ currentglobal //true setglobal
+
+ /UNROLLFORMS true def
+
+-{ } bind dup
++(%.defaultbgrucrproc) cvn { } bind def
++
++(%.defaultbgrucrproc) cvn load dup
+ setblackgeneration
+ setundercolorremoval
+ 0 array cvx readonly dup dup dup setcolortransfer
+@@ -109,3 +116,5 @@ userdict /.smoothness currentsmoothness put
+ % end of slightly nasty hack to give consistent cluster results
+
+ //false 0 startjob pop% re-enter encapsulated mode
++
++%END GS_CET
+diff --git a/Resource/Init/gs_init.ps b/Resource/Init/gs_init.ps
+index 45bebf4..e6b9cd2 100644
+--- a/Resource/Init/gs_init.ps
b/Resource/Init/gs_init.ps
+@@ -1538,10 +1538,18 @@ setpacking
+ % any-part-of-pixel rule.
+ 0.5 .setfilladjust
+ } bind def
++
+ % Set the default screen and BG/UCR.
++% We define the proc here, rather than inline in .setdefaultbgucr
++% for the benefit
Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups exist for package_write_* tasks
On Wed, 2019-04-03 at 14:26 +0200, Peter Kjellerstedt wrote:
> If the populate_lic task and any of the package_write_* tasks need to
> run, but the package task can be restored from the sstate cache, then
> the fetch task, which is a dependency of populate_lic, will wipe out
> the RSS including any users/groups that have been created. This
> results in that the package_write_* tasks are run without any
> user/group information, which causes them to fallback to either use
> the root user for any unknown users/groups (rpm) or to use the
> numeric
> UIDs/GIDs (deb/ipk). Neither solution will yield correct packages.
>
> Signed-off-by: Peter Kjellerstedt
> ---
> meta/classes/useradd.bbclass | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/meta/classes/useradd.bbclass
> b/meta/classes/useradd.bbclass
> index 124becd082..e32315a1af 100644
> --- a/meta/classes/useradd.bbclass
> +++ b/meta/classes/useradd.bbclass
> @@ -4,7 +4,7 @@ inherit useradd_base
> # target sysroot, and shadow -native and -sysroot provide the
> utilities
> # and support files needed to add and modify user and group accounts
> DEPENDS_append_class-target = " base-files shadow-native shadow-
> sysroot shadow base-passwd"
> -PACKAGE_WRITE_DEPS += "shadow-native"
> +PACKAGE_WRITE_DEPS += "shadow-native shadow-sysroot base-passwd"
>
> # This preinstall function can be run in four different contexts:
> #
> @@ -144,7 +144,10 @@ python useradd_sysroot_sstate () {
> task = d.getVar("BB_CURRENTTASK")
> if task == "package_setscene":
> bb.build.exec_func("useradd_sysroot", d)
> -elif task == "prepare_recipe_sysroot":
> +elif (task == "prepare_recipe_sysroot" or
> + task == "package_write_deb" or
> + task == "package_write_ipk" or
> + task == "package_write_rpm"):
> # Used to update this recipe's own sysroot so the
> user/groups are available to do_install
> scriptfile = d.expand("${RECIPE_SYSROOT}${bindir}/postinst-
> useradd-${PN}")
> bb.build.exec_func("useradd_sysroot", d)
> @@ -161,13 +164,16 @@ python useradd_sysroot_sstate () {
> os.chmod(scriptfile, 0o755)
> }
>
> -do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> -SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
> SYSROOTFUNC = ""
> +SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
>
> -SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> +do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> +do_package_write_deb[prefuncs] += "${SYSROOTFUNC}"
> +do_package_write_ipk[prefuncs] += "${SYSROOTFUNC}"
> +do_package_write_rpm[prefuncs] += "${SYSROOTFUNC}"
>
> -SSTATEPREINSTFUNCS_append_class-target = " useradd_sysroot_sstate"
> +SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> +SSTATEPREINSTFUNCS += "${SYSROOTFUNC}"
>
> do_package_setscene[depends] += "${USERADDSETSCENEDEPS}"
> do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}"
This may be a bigger problem that just package_write_*.
This feels like a bad thing to do since there may be other tasks which
also rely on the user information being present. This probably only
fixes one corner case but there are likey others :(.
Possible solutions might be:
a) To wipe out all sstate tasks if we're rerunning do_fetch
b) Preserve the user/group information around the cleaning of the
sysroot
I think we may need to fix this generically...
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] support CONFIG_MODULE_COMPRESS=y
In case, kernel config enables compressed modules, support of
splitting via split_kernel_module_packages won't find any module.
So, first expand module pattern regex to recognize compressed
modules and then objcopy on temporary extacted to extract module
information.
Signed-off-by: Jens Rehsack
---
meta/classes/kernel-module-split.bbclass | 36 +---
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index e8d3eb5105..61819dca99 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -1,31 +1,31 @@
pkg_postinst_modules () {
if [ -z "$D" ]; then
- depmod -a ${KERNEL_VERSION}
+depmod -a ${KERNEL_VERSION}
else
- # image.bbclass will call depmodwrapper after everything is installed,
- # no need to do it here as well
- :
+# image.bbclass will call depmodwrapper after everything is installed,
+# no need to do it here as well
+:
fi
}
pkg_postrm_modules () {
if [ -z "$D" ]; then
- depmod -a ${KERNEL_VERSION}
+depmod -a ${KERNEL_VERSION}
else
- depmodwrapper -a -b $D ${KERNEL_VERSION}
+depmodwrapper -a -b $D ${KERNEL_VERSION}
fi
}
autoload_postinst_fragment() {
if [ x"$D" = "x" ]; then
- modprobe %s || true
+modprobe %s || true
fi
}
PACKAGE_WRITE_DEPS += "kmod-native depmodwrapper-cross"
do_install_append() {
- install -d ${D}${sysconfdir}/modules-load.d/
${D}${sysconfdir}/modprobe.d/
+install -d ${D}${sysconfdir}/modules-load.d/
${D}${sysconfdir}/modprobe.d/
}
PACKAGESPLITFUNCS_prepend = "split_kernel_module_packages "
@@ -44,9 +44,23 @@ python split_kernel_module_packages () {
def extract_modinfo(file):
import tempfile, subprocess
tempfile.tempdir = d.getVar("WORKDIR")
+compressed = re.match( r'.*\.([xg])z$', file)
tf = tempfile.mkstemp()
tmpfile = tf[1]
-cmd = "%sobjcopy -j .modinfo -O binary %s %s" %
(d.getVar("HOST_PREFIX") or "", file, tmpfile)
+if compressed:
+tmpkofile = tmpfile + ".ko"
+if compressed.group(1) == 'g':
+cmd = "gunzip -dc %s > %s" % (file, tmpkofile)
+subprocess.check_call(cmd, shell=True)
+elif compressed.group(1) == 'x':
+cmd = "xz -dc %s > %s" % (file, tmpkofile)
+subprocess.check_call(cmd, shell=True)
+else:
+msg = "Cannot decompress '%s'" % file
+raise msg
+cmd = "%sobjcopy -j .modinfo -O binary %s %s" %
(d.getVar("HOST_PREFIX") or "", tmpkofile, tmpfile)
+else:
+cmd = "%sobjcopy -j .modinfo -O binary %s %s" %
(d.getVar("HOST_PREFIX") or "", file, tmpfile)
subprocess.check_call(cmd, shell=True)
# errors='replace': Some old kernel versions contain invalid utf-8
characters in mod descriptions (like 0xf6, '??')
f = open(tmpfile, errors='replace')
@@ -54,6 +68,8 @@ python split_kernel_module_packages () {
f.close()
os.close(tf[0])
os.unlink(tmpfile)
+if compressed:
+os.unlink(tmpkofile)
vals = {}
for i in l:
m = modinfoexp.match(i)
@@ -133,7 +149,7 @@ python split_kernel_module_packages () {
kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
kernel_version = d.getVar("KERNEL_VERSION")
-module_regex = r'^(.*)\.k?o$'
+module_regex = r'^(.*)\.k?o(?:\.[xg]z)?$'
module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] perl-sanity: support cpan versions of core modules
Most of perl core modules are dual-life modules which exists on CPAN
as well as they do in perl core. Sometime, fixes are uploaded to CPAN
before a new perl is released which contains the fix of the core
module. Also, some modules recent releases aren't fully backported
to earlier releases (out of support, lack of specific feature, ...),
which makes it up to the distribution build to choose between core
or CPAN version, respectively.
Signed-off-by: Jens Rehsack
---
.../perl-sanity/perl_5.28.1.bb| 33 +++
1 file changed, 33 insertions(+)
diff --git a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
index 5aa7cd3ee1..e609c056d0 100644
--- a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
+++ b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
@@ -172,6 +172,39 @@ perl_package_preprocess () {
${PKGD}${libdir}/perl5/config.sh
}
+inherit update-alternatives
+
+ALTERNATIVE_PRIORITY = "100"
+
+ALTERNATIVE_${PN} = "corelist cpan enc2xs encguess h2ph h2xs instmodsh json_pp
libnetcfg \
+ piconv pl2pm pod2html pod2man pod2text pod2usage
podchecker podselect \
+ prove ptar ptardiff ptargrep shasum splain xsubpp
zipdetails"
+ALTERNATIVE_LINK_NAME[corelist] = "${bindir}/corelist"
+ALTERNATIVE_LINK_NAME[cpan] = "${bindir}/cpan"
+ALTERNATIVE_LINK_NAME[enc2xs] = "${bindir}/enc2xs"
+ALTERNATIVE_LINK_NAME[encguess] = "${bindir}/encguess"
+ALTERNATIVE_LINK_NAME[h2ph] = "${bindir}/h2ph"
+ALTERNATIVE_LINK_NAME[h2xs] = "${bindir}/h2xs"
+ALTERNATIVE_LINK_NAME[instmodsh] = "${bindir}/instmodsh"
+ALTERNATIVE_LINK_NAME[json_pp] = "${bindir}/json_pp"
+ALTERNATIVE_LINK_NAME[libnetcfg] = "${bindir}/libnetcfg"
+ALTERNATIVE_LINK_NAME[piconv] = "${bindir}/piconv"
+ALTERNATIVE_LINK_NAME[pl2pm] = "${bindir}/pl2pm"
+ALTERNATIVE_LINK_NAME[pod2html] = "${bindir}/pod2html"
+ALTERNATIVE_LINK_NAME[pod2man] = "${bindir}/pod2man"
+ALTERNATIVE_LINK_NAME[pod2text] = "${bindir}/pod2text"
+ALTERNATIVE_LINK_NAME[pod2usage] = "${bindir}/pod2usage"
+ALTERNATIVE_LINK_NAME[podchecker] = "${bindir}/podchecker"
+ALTERNATIVE_LINK_NAME[podselect] = "${bindir}/podselect"
+ALTERNATIVE_LINK_NAME[prove] = "${bindir}/prove"
+ALTERNATIVE_LINK_NAME[ptar] = "${bindir}/ptar"
+ALTERNATIVE_LINK_NAME[ptardiff] = "${bindir}/ptardiff"
+ALTERNATIVE_LINK_NAME[ptargrep] = "${bindir}/ptargrep"
+ALTERNATIVE_LINK_NAME[shasum] = "${bindir}/shasum"
+ALTERNATIVE_LINK_NAME[splain] = "${bindir}/splain"
+ALTERNATIVE_LINK_NAME[xsubpp] = "${bindir}/xsubpp"
+ALTERNATIVE_LINK_NAME[zipdetails] = "${bindir}/zipdetails"
+
require perl-ptest.inc
FILES_${PN} = "${bindir}/perl ${bindir}/perl.real ${bindir}/perl${PV}
${libdir}/libperl.so* \
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] ghostscript: Fix CVE-2019-3835 and CVE-2019-3838
Have all of these been resolved in master?
Ross
On Wed, 3 Apr 2019 at 13:39, Ovidiu Panait wrote:
>
> It was found that the superexec operator was available in the internal
> dictionary in ghostscript before 9.27. A specially crafted PostScript
> file could use this flaw in order to, for example, have access to the
> file system outside of the constrains imposed by -dSAFER.
>
> It was found that the forceput operator could be extracted from the
> DefineResource method in ghostscript before 9.27. A specially crafted
> PostScript file could use this flaw in order to, for example, have
> access to the file system outside of the constrains imposed by -dSAFER.
>
> References:
> https://nvd.nist.gov/vuln/detail/CVE-2019-3835
> https://nvd.nist.gov/vuln/detail/CVE-2019-3838
>
> Upstream patches:
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=779664d
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e8acf6d
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2055917
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d683d1e
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ed9fcd9
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a82601e
>
> Signed-off-by: Ovidiu Panait
> ---
> .../ghostscript/CVE-2019-3835-0001.patch | 99 ++
> .../ghostscript/CVE-2019-3835-0002.patch | 71 +
> .../ghostscript/CVE-2019-3835-0003.patch | 295 ++
> .../ghostscript/CVE-2019-3835-0004.patch | 167 ++
> .../ghostscript/CVE-2019-3838-0001.patch | 34 ++
> .../ghostscript/CVE-2019-3838-0002.patch | 30 ++
> .../ghostscript/ghostscript_9.26.bb | 6 +
> 7 files changed, 702 insertions(+)
> create mode 100644
> meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
> create mode 100644
> meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0002.patch
> create mode 100644
> meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0003.patch
> create mode 100644
> meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0004.patch
> create mode 100644
> meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3838-0001.patch
> create mode 100644
> meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3838-0002.patch
>
> diff --git
> a/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
> b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
> new file mode 100644
> index 00..30ce04a7b1
> --- /dev/null
> +++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
> @@ -0,0 +1,99 @@
> +From ad3ad6b389653722507e588c5cb34d8731e49e89 Mon Sep 17 00:00:00 2001
> +From: Chris Liddell
> +Date: Mon, 26 Nov 2018 18:01:25 +
> +Subject: [PATCH] Have gs_cet.ps run from gs_init.ps
> +
> +Previously gs_cet.ps was run on the command line, to set up the interpreter
> +state so our output more closely matches the example output for the QL CET
> +tests.
> +
> +Allow a -dCETMODE command line switch, which will cause gs_init.ps to run the
> +file directly.
> +
> +This works better for gpdl as it means the changes are made in the intial
> +interpreter state, rather than after initialisation is complete.
> +
> +This also means adding a definition of the default procedure for black
> +generation and under color removal (rather it being defined in-line in
> +.setdefaultbgucr
> +
> +Also, add a check so gs_cet.ps only runs once - if we try to run it a second
> +time, we'll just skip over the file, flushing through to the end.
> +
> +CVE: CVE-2019-3835
> +Upstream-Status: Backport [git://git.ghostscript.com/ghostpdl.git]
> +
> +Signed-off-by: Ovidiu Panait
> +---
> + Resource/Init/gs_cet.ps | 11 ++-
> + Resource/Init/gs_init.ps | 13 -
> + 2 files changed, 22 insertions(+), 2 deletions(-)
> +
> +diff --git a/Resource/Init/gs_cet.ps b/Resource/Init/gs_cet.ps
> +index d3e1686..75534bb 100644
> +--- a/Resource/Init/gs_cet.ps
> b/Resource/Init/gs_cet.ps
> +@@ -1,6 +1,11 @@
> + %!PS
> + % Set defaults for Ghostscript to match Adobe CPSI behaviour for CET
> +
> ++systemdict /product get (PhotoPRINT SE 5.0v2) readonly eq
> ++{
> ++ (%END GS_CET) .skipeof
> ++} if
> ++
> + % do this in the server level so it is persistent across jobs
> + //true 0 startjob not {
> + (*** Warning: CET startup is not in server default) = flush
> +@@ -25,7 +30,9 @@ currentglobal //true setglobal
> +
> + /UNROLLFORMS true def
> +
> +-{ } bind dup
> ++(%.defaultbgrucrproc) cvn { } bind def
> ++
> ++(%.defaultbgrucrproc) cvn load dup
> + setblackgeneration
> + setundercolorremoval
> + 0 array cvx readonly dup dup dup setcolortransfer
> +@@ -109,3 +116,5 @@ userdict /.smoothness currentsmoothness put
> + % end of slightly nasty hack to give consistent cluster results
> +
> + //false 0 startjob pop% re-enter encapsulated mode
> ++
> ++%END GS_CET
> +diff --git a/Resource/Init/gs_init.ps b/Resource/Init/gs_init
Re: [OE-core] [PATCH] cmake: 3.14.0 -> 3.14.1
On Wed, 2019-04-03 at 09:20 +, Bach, Pascal wrote: > This patch should also go into warrior as I think we should not ship > 3.14.0 due to the issue mentioned bellow. Thanks, will queue this in warrior-next. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] support CONFIG_MODULE_COMPRESS=y
On Wed, 2019-04-03 at 15:18 +0200, Jens Rehsack wrote: > In case, kernel config enables compressed modules, support of > splitting via split_kernel_module_packages won't find any module. > So, first expand module pattern regex to recognize compressed > modules and then objcopy on temporary extacted to extract module > information. > > Signed-off-by: Jens Rehsack > --- > meta/classes/kernel-module-split.bbclass | 36 +- > -- > 1 file changed, 26 insertions(+), 10 deletions(-) There is a lot of whitespace noise in this, could you clean that up and resend please? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] resulttool: Allow store to work on single files
Store operations using a single file as a source weren't working as the os.walk
command didn't like being given a single file. Fix the store operation to
work for single files.
Signed-off-by: Richard Purdie
---
scripts/lib/resulttool/store.py | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/scripts/lib/resulttool/store.py b/scripts/lib/resulttool/store.py
index 5e33716c3dc..3a81933242b 100644
--- a/scripts/lib/resulttool/store.py
+++ b/scripts/lib/resulttool/store.py
@@ -29,15 +29,18 @@ def store(args, logger):
try:
results = {}
logger.info('Reading files from %s' % args.source)
-for root, dirs, files in os.walk(args.source):
-for name in files:
-f = os.path.join(root, name)
-if name == "testresults.json":
-resultutils.append_resultsdata(results, f)
-elif args.all:
-dst = f.replace(args.source, tempdir + "/")
-os.makedirs(os.path.dirname(dst), exist_ok=True)
-shutil.copyfile(f, dst)
+if os.path.isfile(args.source):
+resultutils.append_resultsdata(results, args.source)
+else:
+for root, dirs, files in os.walk(args.source):
+for name in files:
+f = os.path.join(root, name)
+if name == "testresults.json":
+resultutils.append_resultsdata(results, f)
+elif args.all:
+dst = f.replace(args.source, tempdir + "/")
+os.makedirs(os.path.dirname(dst), exist_ok=True)
+shutil.copyfile(f, dst)
revisions = {}
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] resulttool: Allow extraction of ptest data
Rather than simply discarding the ptest data, change the code to discard
it when writing out the new testresult files, or optionally either preserve
it, or write it as seperate discrete logs.
This means the autobuilder should start writing out individual ptest log
files as well as allowing ueers to extract these manually.
Signed-off-by: Richard Purdie
---
scripts/lib/resulttool/resultutils.py | 39 +--
scripts/lib/resulttool/store.py | 2 +-
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/scripts/lib/resulttool/resultutils.py
b/scripts/lib/resulttool/resultutils.py
index 153f2b8e107..ad40ac8499d 100644
--- a/scripts/lib/resulttool/resultutils.py
+++ b/scripts/lib/resulttool/resultutils.py
@@ -15,6 +15,7 @@
import os
import json
import scriptpath
+import copy
scriptpath.add_oe_lib_path()
flatten_map = {
@@ -60,12 +61,6 @@ def append_resultsdata(results, f, configmap=store_map):
testpath = "/".join(data[res]["configuration"].get(i) for i in
configmap[testtype])
if testpath not in results:
results[testpath] = {}
-if 'ptestresult.rawlogs' in data[res]['result']:
-del data[res]['result']['ptestresult.rawlogs']
-if 'ptestresult.sections' in data[res]['result']:
-for i in data[res]['result']['ptestresult.sections']:
-if 'log' in data[res]['result']['ptestresult.sections'][i]:
-del data[res]['result']['ptestresult.sections'][i]['log']
results[testpath][res] = data[res]
#
@@ -93,15 +88,43 @@ def filter_resultsdata(results, resultid):
newresults[r][i] = results[r][i]
return newresults
-def save_resultsdata(results, destdir, fn="testresults.json"):
+def strip_ptestresults(results):
+newresults = copy.deepcopy(results)
+#for a in newresults2:
+# newresults = newresults2[a]
+for res in newresults:
+if 'result' not in newresults[res]:
+continue
+if 'ptestresult.rawlogs' in newresults[res]['result']:
+del newresults[res]['result']['ptestresult.rawlogs']
+if 'ptestresult.sections' in newresults[res]['result']:
+for i in newresults[res]['result']['ptestresult.sections']:
+if 'log' in
newresults[res]['result']['ptestresult.sections'][i]:
+del
newresults[res]['result']['ptestresult.sections'][i]['log']
+return newresults
+
+def save_resultsdata(results, destdir, fn="testresults.json", ptestjson=False,
ptestlogs=False):
for res in results:
if res:
dst = destdir + "/" + res + "/" + fn
else:
dst = destdir + "/" + fn
os.makedirs(os.path.dirname(dst), exist_ok=True)
+resultsout = results[res]
+if not ptestjson:
+resultsout = strip_ptestresults(results[res])
with open(dst, 'w') as f:
-f.write(json.dumps(results[res], sort_keys=True, indent=4))
+f.write(json.dumps(resultsout, sort_keys=True, indent=4))
+for res2 in results[res]:
+if ptestlogs and 'result' in results[res][res2]:
+if 'ptestresult.rawlogs' in results[res][res2]['result']:
+with open(dst.replace(fn, "ptest-raw.log"), "w+") as f:
+
f.write(results[res][res2]['result']['ptestresult.rawlogs']['log'])
+if 'ptestresult.sections' in results[res][res2]['result']:
+for i in
results[res][res2]['result']['ptestresult.sections']:
+if 'log' in
results[res][res2]['result']['ptestresult.sections'][i]:
+with open(dst.replace(fn, "ptest-%s.log" % i),
"w+") as f:
+
f.write(results[res][res2]['result']['ptestresult.sections'][i]['log'])
def git_get_result(repo, tags):
git_objs = []
diff --git a/scripts/lib/resulttool/store.py b/scripts/lib/resulttool/store.py
index 3a81933242b..e4a08075287 100644
--- a/scripts/lib/resulttool/store.py
+++ b/scripts/lib/resulttool/store.py
@@ -68,7 +68,7 @@ def store(args, logger):
results = revisions[r]
keywords = {'commit': r[0], 'branch': r[1], "commit_count": r[2]}
subprocess.check_call(["find", tempdir, "!", "-path", "./.git/*",
"-delete"])
-resultutils.save_resultsdata(results, tempdir)
+resultutils.save_resultsdata(results, tempdir, ptestlogs=True)
logger.info('Storing test result into git repository %s' %
args.git_dir)
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Git commit process question.
On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > The kernel does not have "upgrade foo to the latest upstream version" > > > commits. > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > most of the time there is no specific motivation other than upgrading > > > to the latest upstream version. > > > > But since that's just filling in a template the body can also be a > > template perhaps with useful AUH data (run at ... by ... ?) ? > > Apart from making the commit message longer what does this achieve? > The commit already has a timestamp and author. It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH updates are a form of "trivial update" that every project has. "Update $X from version $Y to $Z" is what a human would normally put. It's weird looking at git log of nothing but subject+signed-off-by. I'm not going to object further on this point, but I don't get it. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libsecret: remove intltool DEPENDS
libsecret 0.18.7 removed intltool and now uses pure gettext. Signed-off-by: Ross Burton --- meta/recipes-gnome/libsecret/libsecret_0.18.7.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-gnome/libsecret/libsecret_0.18.7.bb b/meta/recipes-gnome/libsecret/libsecret_0.18.7.bb index 0061b880533..ba38d107f7a 100644 --- a/meta/recipes-gnome/libsecret/libsecret_0.18.7.bb +++ b/meta/recipes-gnome/libsecret/libsecret_0.18.7.bb @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=23c2a5e0106b99d75238986559bb5fc6" inherit gnomebase gtk-doc vala gobject-introspection manpages -DEPENDS += "glib-2.0 libgcrypt gettext-native intltool-native" +DEPENDS += "glib-2.0 libgcrypt gettext-native" PACKAGECONFIG[manpages] = "--enable-manpages, --disable-manpages, libxslt-native xmlto-native" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] utils.py: added sh_quote() function
This function is a wrapper around "shlex.quote()" and can be used in
"${@...}" context where shlex (or pipes, which provides similar
functionality) is unavailable.
Signed-off-by: Enrico Scholz
---
meta/lib/oe/utils.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 3a496090f3..cedd053d36 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -490,3 +490,6 @@ class ImageQAFailed(bb.build.FuncFailed):
return msg
+def sh_quote(string):
+import shlex
+return shlex.quote(string)
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Git commit process question.
On Wed, Apr 3, 2019 at 7:41 AM Tom Rini wrote: > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > > The kernel does not have "upgrade foo to the latest upstream version" > > > > commits. > > > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > > most of the time there is no specific motivation other than upgrading > > > > to the latest upstream version. > > > > > > But since that's just filling in a template the body can also be a > > > template perhaps with useful AUH data (run at ... by ... ?) ? > > > > Apart from making the commit message longer what does this achieve? > > The commit already has a timestamp and author. > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH > updates are a form of "trivial update" that every project has. "Update > $X from version $Y to $Z" is what a human would normally put. It's > weird looking at git log of nothing but subject+signed-off-by. I'm not > going to object further on this point, but I don't get it. if the content of subject is being repeated in body then I would prefer an empty body redundant information in commits should be avoided since it can create impression that body does not have useful information and skip reading it. We should strive to make commits concise and useful. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/3] cmake-native: Enable ccmake by default and depend on ncurses
On Wed, Apr 3, 2019 at 2:26 AM Bach, Pascal wrote:
>
> >
> > Enable the building of the curses based ui for cmake. This depends on
> > ncurses.
>
> I think this is acceptable. It might also be useful for people wanting to use
> ccmake inside an SDK.
>
Adding dependencies do serialize builds and might have penalty on
build time, better is to turn this into a packageconfig
option and keep it disabled by default.
> > Signed-off-by: Nathan Rossi
> > ---
> > This patch suggests enabling this in the cmake-native recipe, however this
> > might be undesirable for bootstrapping reasons. Whilst ccmake is not used
> > normally the added dependency on ncurses is likely required for other parts
> > of the build so impact on build ordering and time should be relatively
> > minimal.
> >
> > Changes in v2:
> > - None
> > ---
> > meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > index fedcf3d4bd..b2952ee5f5 100644
> > --- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > +++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > @@ -1,7 +1,7 @@
> > require cmake.inc
> > inherit native
> >
> > -DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> > curl-native"
> > +DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> > curl-native ncurses-native"
> >
> > SRC_URI += "file://OEToolchainConfig.cmake \
> > file://environment.d-cmake.sh \ @@ -13,10 +13,9 @@ SRC_URI +=
> > "file://OEToolchainConfig.cmake \ B = "${WORKDIR}/build"
> > do_configure[cleandirs] = "${B}"
> >
> > -# Disable ccmake since we don't depend on ncurses CMAKE_EXTRACONF =
> > "\
> > -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
> > --DBUILD_CursesDialog=0 \
> > +-DBUILD_CursesDialog=1 \
> > -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
> > -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
> > -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \
> > ---
> > 2.20.1
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/9] docbook-xml: use xmlcatalog class
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 --
.../docbook-xml/docbook-xml-dtd4_4.5.bb| 25
2 files changed, 12 insertions(+), 81 deletions(-)
delete mode 100644
meta/recipes-devtools/docbook-xml/docbook-xml-dtd4/docbook-xml.xml
diff --git a/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4/docbook-xml.xml
b/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4/docbook-xml.xml
deleted file mode 100644
index b71f559ef53..000
--- a/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4/docbook-xml.xml
+++ /dev/null
@@ -1,68 +0,0 @@
-
-http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd";>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- http://docbook.org/xml/4.4/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.4/catalog.xml"/>
- http://docbook.org/xml/4.1/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/catalog.xml"/>
-
-
- http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.3/catalog.xml"/>
- http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.5/catalog.xml"/>
-
-
-
-
- http://docbook.org/xml/4.1.2/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.1.2/catalog.xml"/>
-
-
- http://docbook.org/xml/4.5/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.5/catalog.xml"/>
-
-
-
-
- http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.1.2/catalog.xml"/>
-
-
-
-
- http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.2/catalog.xml"/>
- http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.0/catalog.xml"/>
- http://docbook.org/xml/4.2/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.2/catalog.xml"/>
-
-
-
- http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.4/catalog.xml"/>
-
-
- http://docbook.org/xml/4.3/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/4.3/catalog.xml"/>
-
-
-
-
-
- http://www.oasis-open.org/docbook/xml/4.1/docbookx.dtd";
catalog="file:///usr/share/xml/docbook/schema/dtd/catalog.xml"/>
-
diff --git a/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
b/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
index da62b77a602..4b6a28e34c3 100644
--- a/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
+++ b/meta/recipes-devtools/docbook-xml/docbook-xml-dtd4_4.5.bb
@@ -8,13 +8,14 @@ HOMEPAGE = "http://www.docbook.org/xml/";
LICENSE = "OASIS"
LIC_FILES_CHKSUM =
"file://${WORKDIR}/LICENSE-OASIS;md5=c608985dd5f7f215e669e7639a0b1d2e"
+DEPENDS = "libxml2-native"
+
# Note: the upstream sources are not distributed with a license file.
# LICENSE-OASIS is included as a "patch" to workaround this. When
# upgrading this recipe, please verify whether this is still needed.
SRC_URI =
"http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/d/docbook-xml/docbook-xml_${PV}.orig.tar.gz
\
file://LICENSE-OASIS \
file://docbook-xml-update-catalog.xml.patch \
- file://docbook-xml.xml \
"
SRC_URI[md5sum] = "487b4d44e15cffb1f4048af23f98208e"
@@ -22,7 +23,7 @@ SRC_URI[sha256sum] =
"b0f8edcf697f5318e63dd98c9a931f3fee167af0805ba441db372e0f17
UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/docbook-xml/"
-S="${WORKDIR}/docbook-xml-4.5.c31424"
+S = "${WORKDIR}/docbook-xml-4.5.c31424"
inherit allarch
BBCLASSEXTEND = "native"
@@ -36,20 +37,18 @@ do_compile (){
}
do_install () {
-# Refer debian https://packages.debian.org/sid/all/docbook-xml/filelist
+install -d ${D}${sysconfdir}/xml/
+xmlcatalog --create --noout ${D}${sysconfdir}/xml/docbook-xml.xml
+
for DTDVERSION in 4.0 4.1.2 4.2 4.3 4.4 4.5; do
-install -d -m 755 ${D}${datadir}/xml/docbook/schema/dtd/${DTDVERSION}
-cp -v -R docbook-${DTDVERSION}/*
${D}${datadir}/xml/docbook/schema/dtd/${DTDVERSION}
+DEST=${datadir}/xml/docbook/schema/dtd/$DTDVERSION
+install -d -m 755 ${D}$DEST
+cp -v -R docbook-$DTDVERSION/* ${D}$DEST
+xmlcatalog --verbose --noout --add nextCatalog unused
file://$DEST/catalog.xml ${D}${sysconfdir}/xml/docbook-xml.xml
done
-
-install -d ${D}${sysconfdir}/xml/
-install -m 755 ${WORKDIR}/docbook-xml.xml
${D}${sysconfdir}/xml/docbook-xml.xml
}
-do_install_append_class-native () {
- # Ensure that the catalog file s
[OE-core] [PATCH 1/9] xmlcatalog: new class to update the XML catalogue
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 and target use hasn't been implemented yet, it
is possible that the behaviour of this class will change.
[1] https://en.wikipedia.org/wiki/XML_catalog
Signed-off-by: Ross Burton
---
meta/classes/xmlcatalog.bbclass | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 meta/classes/xmlcatalog.bbclass
diff --git a/meta/classes/xmlcatalog.bbclass b/meta/classes/xmlcatalog.bbclass
new file mode 100644
index 000..dc63a0beb4d
--- /dev/null
+++ b/meta/classes/xmlcatalog.bbclass
@@ -0,0 +1,22 @@
+XMLCATALOGS ?= ""
+
+DEPENDS_append_class-native = " libxml2-native"
+SYSROOT_PREPROCESS_FUNCS_append = " xmlcatalog_sstate_postinst"
+
+xmlcatalog_complete() {
+ ROOTCATALOG="${STAGING_ETCDIR_NATIVE}/xml/catalog"
+ if [ ! -f \$ROOTCATALOG ]; then
+ xmlcatalog --noout --create \$ROOTCATALOG
+ fi
+ for CATALOG in ${XMLCATALOGS}; do
+ xmlcatalog --noout --add nextCatalog unused file://\$CATALOG
\$ROOTCATALOG
+ done
+}
+
+xmlcatalog_sstate_postinst() {
+ mkdir -p ${SYSROOT_DESTDIR}${bindir}
+ dest=${SYSROOT_DESTDIR}${bindir}/postinst-${PN}-xmlcatalog
+ echo '#!/bin/sh' > $dest
+ echo "${xmlcatalog_complete}" >> $dest
+ chmod 0755 $dest
+}
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/9] docbook-xsl: neaten documentation
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
a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
b/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
index 07d32ce9795..036fc15dc9a 100644
--- a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
+++ b/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
@@ -42,14 +42,11 @@ do_install () {
ln -s VERSION
${D}/${datadir}/xml/docbook/xsl-stylesheets-${PV}/VERSION.xsl
- install -v -m644 -D README \
- ${D}${datadir}/doc/docbook-xsl-${PV}/README.txt
- install -v -m644RELEASE-NOTES* NEWS* \
- ${D}${datadir}/doc/docbook-xsl-${PV}
+ install -d ${D}${docdir}/${BPN}
+ install -v -m644 README RELEASE-NOTES* NEWS* ${D}${docdir}/${BPN}
install -d ${D}${sysconfdir}/xml/
install -m 755 ${WORKDIR}/docbook-xsl.xml
${D}${sysconfdir}/xml/docbook-xsl.xml
-
}
do_install_append_class-native () {
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/9] docbook-xsl: use xmlcatalog
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 --
.../docbook-xml/docbook-xsl-stylesheets_1.79.1.bb | 21 +++--
2 files changed, 7 insertions(+), 20 deletions(-)
delete mode 100644
meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets/docbook-xsl.xml
diff --git
a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets/docbook-xsl.xml
b/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets/docbook-xsl.xml
deleted file mode 100644
index c60555ae149..000
--- a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets/docbook-xsl.xml
+++ /dev/null
@@ -1,6 +0,0 @@
-
-http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd";>
-
-http://docbook.sourceforge.net/release/xsl/";
catalog="file:///usr/share/xml/docbook/xsl-stylesheets/catalog.xml"/>
-http://docbook.sourceforge.net/release/xsl/";
catalog="file:///usr/share/xml/docbook/xsl-stylesheets/catalog.xml"/>
-
diff --git
a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
b/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
index 036fc15dc9a..ff38e874b3e 100644
--- a/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
+++ b/meta/recipes-devtools/docbook-xml/docbook-xsl-stylesheets_1.79.1.bb
@@ -4,7 +4,6 @@ LICENSE = "XSL"
LIC_FILES_CHKSUM = "file://COPYING;md5=6beadd98f9c54ab0c387e14211ee4d0e"
SRC_URI = "${SOURCEFORGE_MIRROR}/docbook/docbook-xsl-${PV}.tar.bz2 \
- file://docbook-xsl.xml \
file://docbook-xsl-stylesheets-no-bashism-in-docbook-xsl-up.patch \
"
@@ -15,10 +14,11 @@ UPSTREAM_CHECK_URI =
"http://sourceforge.net/projects/docbook/files/docbook-xsl/
# Reject versions ending in .0 as those are release candidates
UPSTREAM_CHECK_REGEX = "/docbook-xsl/(?P(\d+[\.\-_]*)+(?!\.0)\.\d+)/"
+DEPENDS = "libxml2-native"
+
S = "${WORKDIR}/docbook-xsl-${PV}"
-inherit allarch
-BBCLASSEXTEND = "native"
+inherit allarch xmlcatalog
do_configure (){
:
@@ -29,8 +29,6 @@ do_compile (){
}
do_install () {
- # Refer to
http://www.linuxfromscratch.org/blfs/view/stable/pst/docbook-xsl.html
- # for details.
install -v -m755 -d ${D}${datadir}/xml/docbook/xsl-stylesheets-${PV}
ln -s xsl-stylesheets-${PV} ${D}${datadir}/xml/docbook/xsl-stylesheets
@@ -44,17 +42,12 @@ do_install () {
install -d ${D}${docdir}/${BPN}
install -v -m644 README RELEASE-NOTES* NEWS* ${D}${docdir}/${BPN}
-
- install -d ${D}${sysconfdir}/xml/
- install -m 755 ${WORKDIR}/docbook-xsl.xml
${D}${sysconfdir}/xml/docbook-xsl.xml
-}
-
-do_install_append_class-native () {
- # Ensure that the catalog file sgml-docbook.cat is properly
- # updated when the package is installed from sstate cache.
- sed -i -e "s|file://.*/usr/share/xml|file://${datadir}/xml|g"
${D}${sysconfdir}/xml/docbook-xsl.xml
}
RDEPENDS_${PN} += "perl"
FILES_${PN} = "${datadir}/xml/* ${sysconfdir}/xml/docbook-xsl.xml"
FILES_${PN}-doc = "${datadir}/doc/*"
+
+XMLCATALOGS = "${datadir}/xml/docbook/xsl-stylesheets-${PV}/catalog.xml"
+
+BBCLASSEXTEND = "native"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] core-image-sato-sdk-ptest: Fix free space issues causing test failures
Some tests such as strace-ptest require more than the current 500MB of free space. Increase the amount available, staying under the 4GB limit. We have more flexibility now since we shrank kernel-devsrc and the comments are out of date due to that. This should improve the strace-ptest results and the util-linux ones since those sort after strace and also hit the space issues as strace-ptest didn't clean up after itself when failing. Signed-off-by: Richard Purdie --- meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb index 7e3152b4a11..1027ec03be0 100644 --- a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb +++ b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb @@ -4,11 +4,12 @@ DESCRIPTION += "Also includes ptest packages." IMAGE_FEATURES += "ptest-pkgs" -# This image is sufficiently large (~3GB) that it can't actually fit in a live +# This image is sufficiently large (~1.8GB) that we need to be careful that it fits in a live # image (which has a 4GB limit), so nullify the overhead factor (1.3x out of the -# box) and explicitly add just 500MB. +# box) and explicitly add just 1500MB. +# strace-ptest in particular needs more than 500MB IMAGE_OVERHEAD_FACTOR = "1.0" -IMAGE_ROOTFS_EXTRA_SPACE = "524288" +IMAGE_ROOTFS_EXTRA_SPACE = "1524288" # ptests need more memory than standard to avoid the OOM killer QB_MEM = "-m 1024" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/9] xmlto: remove XML catalog
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 break xmlto on the target as the xmlcatalog
class doesn't write a catalog for the target yet, but I'm hoping that nobody
actually uses it on target.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/xmlto/files/catalog.xml | 19 ---
meta/recipes-devtools/xmlto/xmlto_0.0.28.bb | 7 ++-
2 files changed, 2 insertions(+), 24 deletions(-)
delete mode 100644 meta/recipes-devtools/xmlto/files/catalog.xml
diff --git a/meta/recipes-devtools/xmlto/files/catalog.xml
b/meta/recipes-devtools/xmlto/files/catalog.xml
deleted file mode 100644
index 6b8833d871b..000
--- a/meta/recipes-devtools/xmlto/files/catalog.xml
+++ /dev/null
@@ -1,19 +0,0 @@
-
-http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd";>
-
-http://docbook.org/xml/";
catalog="./docbook-xml.xml"/>
-
-
-
-
-
-
-
-
-
-
-http://www.oasis-open.org/docbook/xml/";
catalog="./docbook-xml.xml"/>
-
-http://docbook.sourceforge.net/release/xsl/";
catalog="./docbook-xsl.xml"/>
-http://docbook.sourceforge.net/release/xsl/";
catalog="./docbook-xsl.xml"/>
-
diff --git a/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
b/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
index 6216d7782be..06dc002083d 100644
--- a/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
+++ b/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
@@ -7,7 +7,6 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
SRC_URI = "https://releases.pagure.org/xmlto/xmlto-${PV}.tar.gz \
file://configure.in-drop-the-test-of-xmllint-and-xsltproc.patch \
- file://catalog.xml \
"
SRC_URI[md5sum] = "a1fefad9d83499a15576768f60f847c6"
SRC_URI[sha256sum] =
"2f986b7c9a0e9ac6728147668e776d405465284e13c74d4146c9cbc51fd8aad3"
@@ -32,10 +31,8 @@ BBCLASSEXTEND = "native"
EXTRA_OECONF_append = " BASH=/bin/bash GCP=/bin/cp XMLLINT=xmllint
XSLTPROC=xsltproc"
-do_install_append() {
-install -d ${D}${sysconfdir}/xml/
-install -m 755 ${WORKDIR}/catalog.xml ${D}${sysconfdir}/xml/catalog.xml
-create_wrapper ${D}/${bindir}/xmlto
XML_CATALOG_FILES=${sysconfdir}/xml/catalog.xml
+do_install_append_class-native() {
+create_wrapper ${D}${bindir}/xmlto
XML_CATALOG_FILES=${sysconfdir}/xml/catalog
}
do_populate_sysroot[rdeptask] = "do_populate_sysroot"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 9/9] gtk+: update for new catalog path
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 14ed8d812ca..d6d14a79d5a 100644
--- a/meta/recipes-gnome/gtk+/gtk+.inc
+++ b/meta/recipes-gnome/gtk+/gtk+.inc
@@ -26,7 +26,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES',
'directfb x11', d)}"
PACKAGECONFIG[x11] = "--with-x=yes
--with-gdktarget=x11,--with-x=no,${X11DEPENDS}"
# without --with-gdktarget=directfb it will check for cairo-xlib which isn't
available without X11 DISTRO_FEATURE
PACKAGECONFIG[directfb] = "--with-gdktarget=directfb,,directfb"
-PACKAGECONFIG[manpages] = "--enable-man
--with-xml-catalog=${STAGING_ETCDIR_NATIVE}/xml/catalog.xml, --disable-man,
libxslt-native xmlto-native"
+PACKAGECONFIG[manpages] = "--enable-man
--with-xml-catalog=${STAGING_ETCDIR_NATIVE}/xml/catalog, --disable-man,
libxslt-native xmlto-native"
inherit autotools gtk-doc pkgconfig update-alternatives gtk-immodules-cache
gobject-introspection manpages
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/9] asciidoc: use correct XML catalog path
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 a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
index f684f12dc72..751bf0f19f7 100644
--- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
+++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
@@ -19,7 +19,7 @@ S = "${WORKDIR}/git"
# Tell xmllint where to find the DocBook XML catalogue, because right now it
# opens /etc/xml/catalog on the host. Depends on auto-catalogs.patch
-export SGML_CATALOG_FILES="file://${STAGING_ETCDIR_NATIVE}/xml/docbook-xml.xml
file://${STAGING_ETCDIR_NATIVE}/xml/docbook-xsl.xml"
+export SGML_CATALOG_FILES="file://${STAGING_ETCDIR_NATIVE}/xml/catalog"
# Not using automake
inherit autotools-brokensep
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/9] libxslt: update for new catalog path
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
b/meta/recipes-support/libxslt/libxslt_1.1.33.bb
index fd442d44f72..28d404ca779 100644
--- a/meta/recipes-support/libxslt/libxslt_1.1.33.bb
+++ b/meta/recipes-support/libxslt/libxslt_1.1.33.bb
@@ -36,9 +36,9 @@ RPROVIDES_${PN}-bin += "${PN}-utils"
RCONFLICTS_${PN}-bin += "${PN}-utils"
RREPLACES_${PN}-bin += "${PN}-utils"
-
+# This is only needed until libxml can load the relocated catalog itself
do_install_append_class-native () {
-create_wrapper ${D}/${bindir}/xsltproc
XML_CATALOG_FILES=${sysconfdir}/xml/catalog.xml
+create_wrapper ${D}/${bindir}/xsltproc
XML_CATALOG_FILES=${sysconfdir}/xml/catalog
}
FILES_${PN} += "${libdir}/libxslt-plugins"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 8/9] xmlto: clean up RDEPENDS
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.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/xmlto/xmlto_0.0.28.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
b/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
index 06dc002083d..b17c11f5464 100644
--- a/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
+++ b/meta/recipes-devtools/xmlto/xmlto_0.0.28.bb
@@ -12,16 +12,16 @@ SRC_URI[md5sum] = "a1fefad9d83499a15576768f60f847c6"
SRC_URI[sha256sum] =
"2f986b7c9a0e9ac6728147668e776d405465284e13c74d4146c9cbc51fd8aad3"
inherit autotools
-RDEPENDS_class-native = "libxslt-native"
-# xmlto needs getopt/xmllint/xsltproc/bash/tail at runtime
RDEPENDS_${PN} = "docbook-xml-dtd4 \
docbook-xsl-stylesheets \
util-linux \
libxml2 \
+ libxslt \
bash \
"
RDEPENDS_${PN}_append_class-target = " \
+ libxml2-utils \
libxslt-bin \
coreutils \
"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] support CONFIG_MODULE_COMPRESS=y
> Am 03.04.2019 um 15:58 schrieb Richard Purdie > : > > On Wed, 2019-04-03 at 15:18 +0200, Jens Rehsack wrote: >> In case, kernel config enables compressed modules, support of >> splitting via split_kernel_module_packages won't find any module. >> So, first expand module pattern regex to recognize compressed >> modules and then objcopy on temporary extacted to extract module >> information. >> >> Signed-off-by: Jens Rehsack >> --- >> meta/classes/kernel-module-split.bbclass | 36 +- >> -- >> 1 file changed, 26 insertions(+), 10 deletions(-) > > There is a lot of whitespace noise in this, could you clean that up and > resend please? It's because of s were replaced with spaces - which is reasonable when python code is mixed in. Sure that you want keep the tab's? Cheers -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] support CONFIG_MODULE_COMPRESS=y
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: > > > In case, kernel config enables compressed modules, support of > > > splitting via split_kernel_module_packages won't find any module. > > > So, first expand module pattern regex to recognize compressed > > > modules and then objcopy on temporary extacted to extract module > > > information. > > > > > > Signed-off-by: Jens Rehsack > > > --- > > > meta/classes/kernel-module-split.bbclass | 36 + > > > - > > > -- > > > 1 file changed, 26 insertions(+), 10 deletions(-) > > > > There is a lot of whitespace noise in this, could you clean that up > > and > > resend please? > > It's because of s were replaced with spaces - which is > reasonable when python code is mixed in. > Sure that you want keep the tab's? Rightly or wrongly, the style convention for OE-Core is tabs in shell, spaces in python (I'd prefer not to open that can of worms again right now). Whitespace changes need to be in a separate patch to code changes regardless. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb
I appreciate the nagging about testing, but I just did an update and realized these patches never made it into master so I could request they move into thud. Philip On 02/21/2019 03:37 AM, Richard Purdie wrote: > On Thu, 2019-02-21 at 03:53 +, Manjukumar Harthikote Matha wrote: >> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] >>> On Tue, 2019-02-19 at 19:34 +, Manjukumar Harthikote Matha >>> > PREFERRED_PROVIDER_virtual/dtb = "devicetree" > Yes, I should have added this in the commit message. I will update it and re-send V2 >>> >>> What may also help a lot here would be some tests. This is >>> currently a blackhole in >>> the tests :( >>> >> Are there examples of having tests only for bbclass in OE-Core? > > There are. See meta/lib/oeqa/selftest/cases/wic.py > > I appreciate wic is a tool, not a class but the examples there should > help. You can trigger them with oe-selftest -r wic. > > Another example which is a bbclass is selftest/cases/archiver.py which > does use a class inherit. > >> We need a recipe or create-one to inherit this class and probably add >> that as a testcase. >> I am not sure how to proceed, any example would help to implement the >> same > > See above, they show how to add small config fragments. If you do need > a full recipe, then the meta-selftest layer of OE-Core should be able > to help too. > > If you have any other questions or run into issues please do ask! > > Cheers, > > Richard > > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk wrote: > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote: > >... > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t" > > which is the convention used throughout all the tune files. > >... > > Unfortunately this is not true. > > OE has both armv7a and armv7at tunes. > > There is no armv7a without Thumb support, > so no -march=armv7-at exists in gcc. > > Both armv7a and armv7at tunes pass the same march to gcc, > but [1] is not true: > Default to using the Thumb-2 instruction set for armv7a and above. > > The hardware supports Thumb-2 in any case, the actual difference between > the armv7a and armv7at OE tunes is whether OE tells the compiler to > generate ARM or Thumb-2 code. > > OE has both armv6 and armv6t tunes. > > There is no armv6 without Thumb support > so no -march=armv6t exists in gcc. > > Some v6 support only Thumb-1 and some v6 support also Thumb-2, > so what gcc does have is an -march=armv6t2. > But OE lacks tunes for that. > > For matching the gcc options it would be correct to remove all > armv6t and armv7at tunes that have no coresponding gcc options, > and add armv6t2 tunes. Aligning the tuning options exposed via the machine config files to those supported by gcc seems like a worthy goal... but would be a big upheaval at this point. Note that the problem isn't specific to ARM. There are similar issues for x86, but there we seem happy to provide a very minimal abstraction with no attempt to track gcc. e.g. "corei7" hasn't been a documented -march option since gcc 4.8 and we (somewhat arbitrarily) map it to -march=nehalem to hide that fact from end users. So the high level question seems to be: should DEFAULTTUNE even attempt to provide a full featured mapping to the options provided by gcc? Are we happy to expose a limited subset without a 1:1 mapping for the options we do expose (current ARM approach) or is it better for DEFAULTTUNE to hide away all the complexity of the options provided by gcc (current x86 approach). > And that's only for the legacy 32bit platforms. > > armv8 already has 21 feature modifiers in gcc 9, > and while not all 2^21 or 3^21[2] combinations are > valid the old tune approach won't scale for that. > > > Cheers, > > > > Richard > > cu > Adrian > > [1] > https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-miscellaneous-changes > [2] enable/disable/default > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote: > On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk wrote: > > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote: > > >... > > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t" > > > which is the convention used throughout all the tune files. > > >... > > > > Unfortunately this is not true. > > > > OE has both armv7a and armv7at tunes. > > > > There is no armv7a without Thumb support, > > so no -march=armv7-at exists in gcc. > > > > Both armv7a and armv7at tunes pass the same march to gcc, > > but [1] is not true: > > Default to using the Thumb-2 instruction set for armv7a and above. > > > > The hardware supports Thumb-2 in any case, the actual difference between > > the armv7a and armv7at OE tunes is whether OE tells the compiler to > > generate ARM or Thumb-2 code. > > > > OE has both armv6 and armv6t tunes. > > > > There is no armv6 without Thumb support > > so no -march=armv6t exists in gcc. > > > > Some v6 support only Thumb-1 and some v6 support also Thumb-2, > > so what gcc does have is an -march=armv6t2. > > But OE lacks tunes for that. > > > > For matching the gcc options it would be correct to remove all > > armv6t and armv7at tunes that have no coresponding gcc options, > > and add armv6t2 tunes. > > Aligning the tuning options exposed via the machine config files to > those supported by gcc seems like a worthy goal... but would be a big > upheaval at this point. > > Note that the problem isn't specific to ARM. There are similar issues > for x86, but there we seem happy to provide a very minimal abstraction > with no attempt to track gcc. e.g. "corei7" hasn't been a documented > -march option since gcc 4.8 and we (somewhat arbitrarily) map it to > -march=nehalem to hide that fact from end users. > > So the high level question seems to be: should DEFAULTTUNE even > attempt to provide a full featured mapping to the options provided by > gcc? Are we happy to expose a limited subset without a 1:1 mapping for > the options we do expose (current ARM approach) or is it better for > DEFAULTTUNE to hide away all the complexity of the options provided by > gcc (current x86 approach). The current 32bit ARM[1] approach seems to be an attempt of a 1:1 mapping. For ARMv8 it is already obvious that DEFAULTTUNE is not long-term maintainable, and duplicating all the gcc rules regarding feature flags[2] also sounds like a pointless exercise. What are actually the benefits of DEFAULTTUNE with all the tune files, compared to just let the user provide a string that is passed to -march? cu Adrian [1] ARM <= v7, not the differing 32bit ABI of ARMv8 [2] example: 'fp16fml' Enable FP16 fmla extension. This also enables FP16 extensions and floating-point instructions. This option is enabled by default for '-march=armv8.4-a'. Use of this option with architectures prior to Armv8.2-A is not supported. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
On Wed, Apr 3, 2019 at 1:24 PM Adrian Bunk wrote: > On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote: > > On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk wrote: > > > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote: > > > >... > > > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t" > > > > which is the convention used throughout all the tune files. > > > >... > > > > > > Unfortunately this is not true. > > > > > > OE has both armv7a and armv7at tunes. > > > > > > There is no armv7a without Thumb support, > > > so no -march=armv7-at exists in gcc. > > > > > > Both armv7a and armv7at tunes pass the same march to gcc, > > > but [1] is not true: > > > Default to using the Thumb-2 instruction set for armv7a and above. > > > > > > The hardware supports Thumb-2 in any case, the actual difference between > > > the armv7a and armv7at OE tunes is whether OE tells the compiler to > > > generate ARM or Thumb-2 code. > > > > > > OE has both armv6 and armv6t tunes. > > > > > > There is no armv6 without Thumb support > > > so no -march=armv6t exists in gcc. > > > > > > Some v6 support only Thumb-1 and some v6 support also Thumb-2, > > > so what gcc does have is an -march=armv6t2. > > > But OE lacks tunes for that. > > > > > > For matching the gcc options it would be correct to remove all > > > armv6t and armv7at tunes that have no coresponding gcc options, > > > and add armv6t2 tunes. > > > > Aligning the tuning options exposed via the machine config files to > > those supported by gcc seems like a worthy goal... but would be a big > > upheaval at this point. > > > > Note that the problem isn't specific to ARM. There are similar issues > > for x86, but there we seem happy to provide a very minimal abstraction > > with no attempt to track gcc. e.g. "corei7" hasn't been a documented > > -march option since gcc 4.8 and we (somewhat arbitrarily) map it to > > -march=nehalem to hide that fact from end users. > > > > So the high level question seems to be: should DEFAULTTUNE even > > attempt to provide a full featured mapping to the options provided by > > gcc? Are we happy to expose a limited subset without a 1:1 mapping for > > the options we do expose (current ARM approach) or is it better for > > DEFAULTTUNE to hide away all the complexity of the options provided by > > gcc (current x86 approach). > > The current 32bit ARM[1] approach seems to be an attempt > of a 1:1 mapping. > > For ARMv8 it is already obvious that DEFAULTTUNE is not long-term > maintainable, and duplicating all the gcc rules regarding feature > flags[2] also sounds like a pointless exercise. > > What are actually the benefits of DEFAULTTUNE with all the tune files, > compared to just let the user provide a string that is passed to -march? Restricting the user to a certain set of DEFAULTTUNE options means there will always be a valid mapping from DEFAULTTUNE to PACKAGE_EXTRA_ARCHS. 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. Whether or not anyone in the real world actually maintains a generic package feed and pulls from it from multiple machine specific builds (verses setting up separate package feeds for each DEFAULTTUNE they care about) would be an interesting question... > cu > Adrian > > [1] ARM <= v7, not the differing 32bit ABI of ARMv8 > [2] example: > 'fp16fml' > Enable FP16 fmla extension. This also enables FP16 extensions and > floating-point instructions. This option is enabled by default for > '-march=armv8.4-a'. Use of this option with architectures prior to > Armv8.2-A is not supported. > > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] [oe] Git commit process question.
On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote: > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini wrote: > > > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > > > The kernel does not have "upgrade foo to the latest upstream > > > > > version" commits. > > > > > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > > > most of the time there is no specific motivation other than > > > > > upgrading > > > > > to the latest upstream version. > > > > > > > > But since that's just filling in a template the body can also be a > > > > template perhaps with useful AUH data (run at ... by ... ?) ? > > > > > > Apart from making the commit message longer what does this achieve? > > > The commit already has a timestamp and author. > > > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH > > updates are a form of "trivial update" that every project has. "Update > > $X from version $Y to $Z" is what a human would normally put. It's > > weird looking at git log of nothing but subject+signed-off-by. I'm not > > going to object further on this point, but I don't get it. > > if the content of subject is being repeated in body then I would > prefer an empty body > redundant information in commits should be avoided since it can create > impression that body does not have > useful information and skip reading it. We should strive to make commits > concise and useful. There is often (I won't say always, but often) something useful you can put in the commit message. If it's a recipe upgrade, you could put a pointer to the upstream changelog in it, for example. As the person doing the upgrade if your prior review of that changelog or other upstream release documentation indicated any backwards-compatibility issues or CVEs fixed then those really ought to be mentioned as well; if you're feeling especially generous you might mention highlights of any new functionality. (I have a proposal that might help us automate part of that which I've not yet fully fleshed out, hopefully one day soon I will get around to it.) The issue of empty commit messages is something I've complained about in the past, and not just about recipe upgrades. If I - as someone who is relatively familiar with OE - have to actually read beyond the shortlog / commit message to understand the basics of why a change has been made, then it's likely that the commit message wasn't good enough. Unlike other issues, once a commit goes in the message is set in stone within the git history, so if you are working on a change, *please* take a minute or two to document it adequately in the commit message so that others looking back can understand it. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] [oe] Git commit process question.
On Wed, Apr 3, 2019 at 4:07 PM Paul Eggleton wrote: > > On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote: > > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini wrote: > > > > > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > > > > The kernel does not have "upgrade foo to the latest upstream > > > > > > version" commits. > > > > > > > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > > > > most of the time there is no specific motivation other than > > > > > > upgrading > > > > > > to the latest upstream version. > > > > > > > > > > But since that's just filling in a template the body can also be a > > > > > template perhaps with useful AUH data (run at ... by ... ?) ? > > > > > > > > Apart from making the commit message longer what does this achieve? > > > > The commit already has a timestamp and author. > > > > > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH > > > updates are a form of "trivial update" that every project has. "Update > > > $X from version $Y to $Z" is what a human would normally put. It's > > > weird looking at git log of nothing but subject+signed-off-by. I'm not > > > going to object further on this point, but I don't get it. > > > > if the content of subject is being repeated in body then I would > > prefer an empty body > > redundant information in commits should be avoided since it can create > > impression that body does not have > > useful information and skip reading it. We should strive to make commits > > concise and useful. > > There is often (I won't say always, but often) something useful you can put in > the commit message. If it's a recipe upgrade, you could put a pointer to the > upstream changelog in it, for example. As the person doing the upgrade if your > prior review of that changelog or other upstream release documentation > indicated any backwards-compatibility issues or CVEs fixed then those really > ought to be mentioned as well; if you're feeling especially generous you might > mention highlights of any new functionality. (I have a proposal that might > help us automate part of that which I've not yet fully fleshed out, hopefully > one day soon I will get around to it.) > > The issue of empty commit messages is something I've complained about in the > past, and not just about recipe upgrades. If I - as someone who is relatively > familiar with OE - have to actually read beyond the shortlog / commit message > to understand the basics of why a change has been made, then it's likely that > the commit message wasn't good enough. Unlike other issues, once a commit goes > in the message is set in stone within the git history, so if you are working > on a change, *please* take a minute or two to document it adequately in the > commit message so that others looking back can understand it. > 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 as explained > Thanks, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized
On 4/3/19 5:58 PM, Adrian Bunk wrote:
On Wed, Apr 03, 2019 at 10:29:08AM +0800, Changqing Li wrote:
On 4/2/19 7:31 PM, Adrian Bunk wrote:
On Tue, Apr 02, 2019 at 05:08:33PM +0800, changqing...@windriver.com wrote:
From: Changqing Li
fix below compile error with -Werror=maybe-uninitialized
| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error:
'gltype' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
| *out_gltype = gltype;
| ^~~~
| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error:
'glintformat' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
| *out_glintformat = glintformat;
| ~^
...
Looking at the code, is this a failure that only happens with DEBUG_FLAGS?
Yes, only happen with DEBUG_FLAGS
+--- a/cogl/driver/gl/gles/cogl-driver-gles.c
b/cogl/driver/gl/gles/cogl-driver-gles.c
+@@ -74,9 +74,9 @@ _cogl_driver_pixel_format_to_gl (CoglContext *context,
+ GLenum *out_gltype)
+ {
+ CoglPixelFormat required_format;
+- GLenum glintformat;
++ GLenum glintformat = 0;
+ GLenum glformat = 0;
+- GLenum gltype;
++ GLenum gltype = 0;
...
Assigning random values to variables is a bug,
they do not even seem to be valid values for these variables.
According to code logic, glformat and glintformat will assigned
simultaneously and usually with same value,
But glformat has an assert later to ensure the 0 doesn't leak anywhere.
and 0 mean invalid pixel format.
For pixel format 0 means COGL_PIXEL_FORMAT_ANY.
For glintformat I don't know what would happen if 0 is used.
[snip]
case COGL_PIXEL_FORMAT_DEPTH_24_STENCIL_8:
glintformat = GL_DEPTH_STENCIL;
glformat = GL_DEPTH_STENCIL;
gltype = GL_UNSIGNED_INT_24_8;
break;
and for gtype, there also should be no problem according to the code logic.
According to the current code.
If some future change breaks the code, it would pass invalid data at
runtime instead of giving a compile warning.
and the fix is just for eliminate the error when DEBUG_FLAGS is enabled.
Looking at the code, does passing --enable-maintainer-flags=no
to configure work around this gcc bug
Hi, Adrian
Thanks for your detailed comments. And the future change wrong is
reasonable, but according to
current code, seems it can assert from g_assert_not_reached or g_assert
when glformat/glintformat is not assigned new value.
[snip]
case xxx
glformat=xxx
glintformat=xxx
case COGL_PIXEL_FORMAT_ANY:
case COGL_PIXEL_FORMAT_YUV:
g_assert_not_reached ();
break;
}
/* All of the pixel formats are handled above so if this hits then
we've been given an invalid pixel format */
g_assert (glformat != 0);
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
so I think we can fix same way under this
cogl/driver/gl/gles/cogl-driver-gles.c
cu
Adrian
--
BRs
Sandy(Li Changqing)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] core-image-sato-sdk-ptest: Fix free space issues causing test failures
On 4/3/19 10:04 AM, Richard Purdie wrote: > Some tests such as strace-ptest require more than the current 500MB of free > space. Increase the amount available, staying under the 4GB limit. We have > more > flexibility now since we shrank kernel-devsrc and the comments are out of date > due to that. Won't this be more of a common issue for any image that pulls in the same stuff is is not named sato? - armin > This should improve the strace-ptest results and the util-linux ones since > those sort after strace and also hit the space issues as strace-ptest didn't > clean up after itself when failing. > > Signed-off-by: Richard Purdie > --- > meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb > b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb > index 7e3152b4a11..1027ec03be0 100644 > --- a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb > +++ b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb > @@ -4,11 +4,12 @@ DESCRIPTION += "Also includes ptest packages." > > IMAGE_FEATURES += "ptest-pkgs" > > -# This image is sufficiently large (~3GB) that it can't actually fit in a > live > +# This image is sufficiently large (~1.8GB) that we need to be careful that > it fits in a live > # image (which has a 4GB limit), so nullify the overhead factor (1.3x out of > the > -# box) and explicitly add just 500MB. > +# box) and explicitly add just 1500MB. > +# strace-ptest in particular needs more than 500MB > IMAGE_OVERHEAD_FACTOR = "1.0" > -IMAGE_ROOTFS_EXTRA_SPACE = "524288" > +IMAGE_ROOTFS_EXTRA_SPACE = "1524288" > > # ptests need more memory than standard to avoid the OOM killer > QB_MEM = "-m 1024" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb
On 4/3/19 10:35 AM, Philip Balister wrote: > I appreciate the nagging about testing, but I just did an update and > realized these patches never made it into master so I could request they > move into thud. Thud needs testing too, its not just a master thing. It needs to be in warrior first ; ) Either send me the master/warrior commit ids or send a patch with the proper subject so its clear to me. But this looks like a new feature or am I misunderstanding? - armin > > Philip > > On 02/21/2019 03:37 AM, Richard Purdie wrote: >> On Thu, 2019-02-21 at 03:53 +, Manjukumar Harthikote Matha wrote: >>> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] On Tue, 2019-02-19 at 19:34 +, Manjukumar Harthikote Matha >> PREFERRED_PROVIDER_virtual/dtb = "devicetree" >> > Yes, I should have added this in the commit message. I will > update it > and re-send V2 What may also help a lot here would be some tests. This is currently a blackhole in the tests :( >>> Are there examples of having tests only for bbclass in OE-Core? >> There are. See meta/lib/oeqa/selftest/cases/wic.py >> >> I appreciate wic is a tool, not a class but the examples there should >> help. You can trigger them with oe-selftest -r wic. >> >> Another example which is a bbclass is selftest/cases/archiver.py which >> does use a class inherit. >> >>> We need a recipe or create-one to inherit this class and probably add >>> that as a testcase. >>> I am not sure how to proceed, any example would help to implement the >>> same >> See above, they show how to add small config fragments. If you do need >> a full recipe, then the meta-selftest layer of OE-Core should be able >> to help too. >> >> If you have any other questions or run into issues please do ask! >> >> Cheers, >> >> Richard >> >> >> >> -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] resulttool/resultutils: Enable add extra configurations to results
Current resultutils library always add "TESTSERIES" configuration
to results. Enhance this to allow control of adding "TESTSERIES"
configuration as well as allow adding extra configurations
when needed.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/resultutils.py | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/scripts/lib/resulttool/resultutils.py
b/scripts/lib/resulttool/resultutils.py
index 153f2b8..bfbd381 100644
--- a/scripts/lib/resulttool/resultutils.py
+++ b/scripts/lib/resulttool/resultutils.py
@@ -39,10 +39,12 @@ store_map = {
"manual": ['TEST_TYPE', 'TEST_MODULE', 'MACHINE', 'IMAGE_BASENAME']
}
+extra_configs = {'TESTSERIES': ''}
+
#
# Load the json file and append the results data into the provided results dict
#
-def append_resultsdata(results, f, configmap=store_map):
+def append_resultsdata(results, f, configmap=store_map, configs=extra_configs):
if type(f) is str:
with open(f, "r") as filedata:
data = json.load(filedata)
@@ -51,12 +53,15 @@ def append_resultsdata(results, f, configmap=store_map):
for res in data:
if "configuration" not in data[res] or "result" not in data[res]:
raise ValueError("Test results data without configuration or
result section?")
-if "TESTSERIES" not in data[res]["configuration"]:
-data[res]["configuration"]["TESTSERIES"] =
os.path.basename(os.path.dirname(f))
+for config in configs:
+if config == "TESTSERIES" and "TESTSERIES" not in
data[res]["configuration"]:
+data[res]["configuration"]["TESTSERIES"] =
os.path.basename(os.path.dirname(f))
+continue
+if config not in data[res]["configuration"]:
+data[res]["configuration"][config] = configs[config]
testtype = data[res]["configuration"].get("TEST_TYPE")
if testtype not in configmap:
raise ValueError("Unknown test type %s" % testtype)
-configvars = configmap[testtype]
testpath = "/".join(data[res]["configuration"].get(i) for i in
configmap[testtype])
if testpath not in results:
results[testpath] = {}
@@ -72,16 +77,16 @@ def append_resultsdata(results, f, configmap=store_map):
# Walk a directory and find/load results data
# or load directly from a file
#
-def load_resultsdata(source, configmap=store_map):
+def load_resultsdata(source, configmap=store_map, configs=extra_configs):
results = {}
if os.path.isfile(source):
-append_resultsdata(results, source, configmap)
+append_resultsdata(results, source, configmap, configs)
return results
for root, dirs, files in os.walk(source):
for name in files:
f = os.path.join(root, name)
if name == "testresults.json":
-append_resultsdata(results, f, configmap)
+append_resultsdata(results, f, configmap, configs)
return results
def filter_resultsdata(results, resultid):
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v03] resulttool/merge: enhance merge and control testseries
v01: Enable merging results where both base and target are directory. v02: Follow suggestion from RP to reused the existing resultutils code base where it will merge results to flat file. Refactor resultutils code base to enable merging results where both base and target are directory. Add control for creation of testseries configuration. v03: Follow suggestion from RP to breakdown the patches to ease reviewing. Enable resultutils library to control the adding of "TESTSERIES" configuration as well as allow adding extra configurations when needed. Enable store to add "EXECUTED_BY" configuration to track who executed each results file. Enable merge to control the adding of "TESTSERIES" configuration as well as allow adding "EXECUTED_BY" configuration when needed. Yeoh Ee Peng (3): resulttool/resultutils: Enable add extra configurations to results resulttool/store: Enable add EXECUTED_BY config to results resulttool/merge: Enable control TESTSERIES and extra configurations scripts/lib/resulttool/merge.py | 20 ++-- scripts/lib/resulttool/resultutils.py | 19 --- scripts/lib/resulttool/store.py | 7 ++- 3 files changed, 32 insertions(+), 14 deletions(-) -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] resulttool/store: Enable add EXECUTED_BY config to results
Current results stored does not have information needed to trace who
executed the tests. Enable store to add EXECUTED_BY configuration
to results file in order to track who executed the tests.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/store.py | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/resulttool/store.py b/scripts/lib/resulttool/store.py
index 5e33716..7e89692 100644
--- a/scripts/lib/resulttool/store.py
+++ b/scripts/lib/resulttool/store.py
@@ -27,13 +27,16 @@ import oeqa.utils.gitarchive as gitarchive
def store(args, logger):
tempdir = tempfile.mkdtemp(prefix='testresults.')
try:
+configs = resultutils.extra_configs.copy()
+if args.executed_by:
+configs['EXECUTED_BY'] = args.executed_by
results = {}
logger.info('Reading files from %s' % args.source)
for root, dirs, files in os.walk(args.source):
for name in files:
f = os.path.join(root, name)
if name == "testresults.json":
-resultutils.append_resultsdata(results, f)
+resultutils.append_resultsdata(results, f, configs=configs)
elif args.all:
dst = f.replace(args.source, tempdir + "/")
os.makedirs(os.path.dirname(dst), exist_ok=True)
@@ -96,4 +99,6 @@ def register_commands(subparsers):
help='include all files, not just
testresults.json files')
parser_build.add_argument('-e', '--allow-empty', action='store_true',
help='don\'t error if no results to store are
found')
+parser_build.add_argument('-x', '--executed-by', default='',
+ help='add executed-by configuration to each
result file')
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] resulttool/merge: Enable control TESTSERIES and extra configurations
Current QA team need to merge test result files from multiple sources.
Adding TESTSERIES configuration too early will have negative
implication to report and regression. Enable control to add TESTSERIES
when needed. Also enable adding EXECUTED_BY configuration when
needed.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/merge.py | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/scripts/lib/resulttool/merge.py b/scripts/lib/resulttool/merge.py
index 3e4b7a3..d40a72d 100644
--- a/scripts/lib/resulttool/merge.py
+++ b/scripts/lib/resulttool/merge.py
@@ -17,16 +17,21 @@ import json
import resulttool.resultutils as resultutils
def merge(args, logger):
+configs = {}
+if not args.not_add_testseries:
+configs = resultutils.extra_configs.copy()
+if args.executed_by:
+configs['EXECUTED_BY'] = args.executed_by
if os.path.isdir(args.target_results):
-results = resultutils.load_resultsdata(args.target_results,
configmap=resultutils.store_map)
-resultutils.append_resultsdata(results, args.base_results,
configmap=resultutils.store_map)
+results = resultutils.load_resultsdata(args.target_results,
configmap=resultutils.store_map, configs=configs)
+resultutils.append_resultsdata(results, args.base_results,
configmap=resultutils.store_map, configs=configs)
resultutils.save_resultsdata(results, args.target_results)
else:
-results = resultutils.load_resultsdata(args.base_results,
configmap=resultutils.flatten_map)
+results = resultutils.load_resultsdata(args.base_results,
configmap=resultutils.flatten_map, configs=configs)
if os.path.exists(args.target_results):
-resultutils.append_resultsdata(results, args.target_results,
configmap=resultutils.flatten_map)
+resultutils.append_resultsdata(results, args.target_results,
configmap=resultutils.flatten_map, configs=configs)
resultutils.save_resultsdata(results,
os.path.dirname(args.target_results), fn=os.path.basename(args.target_results))
-
+logger.info('Merged results to %s' % os.path.dirname(args.target_results))
return 0
def register_commands(subparsers):
@@ -39,4 +44,7 @@ def register_commands(subparsers):
help='the results file/directory to import')
parser_build.add_argument('target_results',
help='the target file or directory to merge the
base_results with')
-
+parser_build.add_argument('-t', '--not-add-testseries',
action='store_true',
+ help='do not add testseries configuration to
results')
+parser_build.add_argument('-x', '--executed-by', default='',
+ help='add executed-by configuration to each
result file')
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/3] cmake-native: Enable ccmake by default and depend on ncurses
On Thu, 4 Apr 2019 at 03:02, Khem Raj wrote:
>
> On Wed, Apr 3, 2019 at 2:26 AM Bach, Pascal wrote:
> >
> > >
> > > Enable the building of the curses based ui for cmake. This depends on
> > > ncurses.
> >
> > I think this is acceptable. It might also be useful for people wanting to
> > use ccmake inside an SDK.
Just to be clear, this change only affects cmake-native, the recipe
for target/nativesdk is unchanged. Although interestingly the cmake
(target/nativesdk) recipe already depends on ncurses (despite
disabling ccmake).
> >
>
> Adding dependencies do serialize builds and might have penalty on
> build time, better is to turn this into a packageconfig
> option and keep it disabled by default.
I can rework this patch to make it a PACKAGECONFIG option. However the
reason for enabling ccmake by default is due to the addition of the
ccmake bbclass in this series, which relies on having ccmake available
in the native sysroot. Having to override PACKAGECONFIG to use the
ccmake class seemed broken (since it is not particularly a distro
config).
I could not find a good example of this sort of requirement for
configuration for any other bbclass except for maybe
gobject-introspection (which relies on qemu-native configured
correctly to have linux-user for the target).
Another approach I considered to have this working without requiring
the user to setup PACKAGECONFIG would be to have a "ccmake-native"
recipe which built the ccmake binary. But this seemed like it would be
extra maintenance burden compared to this patch which has minimal
build time overhead.
Regards,
Nathan
>
> > > Signed-off-by: Nathan Rossi
> > > ---
> > > This patch suggests enabling this in the cmake-native recipe, however this
> > > might be undesirable for bootstrapping reasons. Whilst ccmake is not used
> > > normally the added dependency on ncurses is likely required for other
> > > parts
> > > of the build so impact on build ordering and time should be relatively
> > > minimal.
> > >
> > > Changes in v2:
> > > - None
> > > ---
> > > meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > index fedcf3d4bd..b2952ee5f5 100644
> > > --- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > +++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > @@ -1,7 +1,7 @@
> > > require cmake.inc
> > > inherit native
> > >
> > > -DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> > > curl-native"
> > > +DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> > > curl-native ncurses-native"
> > >
> > > SRC_URI += "file://OEToolchainConfig.cmake \
> > > file://environment.d-cmake.sh \ @@ -13,10 +13,9 @@ SRC_URI +=
> > > "file://OEToolchainConfig.cmake \ B = "${WORKDIR}/build"
> > > do_configure[cleandirs] = "${B}"
> > >
> > > -# Disable ccmake since we don't depend on ncurses CMAKE_EXTRACONF =
> > > "\
> > > -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
> > > --DBUILD_CursesDialog=0 \
> > > +-DBUILD_CursesDialog=1 \
> > > -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
> > > -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
> > > -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \
> > > ---
> > > 2.20.1
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sysstat: Fixed the compiling error when configured with '--enable-install-cron'
Remove the handling of enable/disable sysstat.service self-start in Makefile.in. The code will trigger below error when cross compiling with '--enable-install-cron': | if [ -x "/path/to/sysstat/11.7.1-r0/recipe-sysroot-native/usr/bin/systemctl" ]; then \ | /path/to/sysstat/11.7.1-r0/recipe-sysroot-native/usr/bin/systemctl enable sysstat.service; \ | fi | Started /path/to/sysstat/11.7.1-r0/recipe-sysroot-native/usr/bin/systemctl enable sysstat.service | Try to find location of sysstat.service... | 'sysstat.service' couldn't be found; exiting with error It's better to let user enable/disable the service with 'systemctl enable/disable sysstat.service' Signed-off-by: Haiqing Bai --- ...code-of-handling-enable-disable-self-star.patch | 55 ++ meta/recipes-extended/sysstat/sysstat_11.7.1.bb| 3 +- 2 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-extended/sysstat/sysstat/0001-Remove-the-code-of-handling-enable-disable-self-star.patch diff --git a/meta/recipes-extended/sysstat/sysstat/0001-Remove-the-code-of-handling-enable-disable-self-star.patch b/meta/recipes-extended/sysstat/sysstat/0001-Remove-the-code-of-handling-enable-disable-self-star.patch new file mode 100644 index 000..1d099c9 --- /dev/null +++ b/meta/recipes-extended/sysstat/sysstat/0001-Remove-the-code-of-handling-enable-disable-self-star.patch @@ -0,0 +1,55 @@ +From 85813d1648b03ba0497635c45e90d7edf4dc204c Mon Sep 17 00:00:00 2001 +From: Haiqing Bai +Date: Fri, 29 Mar 2019 11:00:09 +0800 +Subject: [PATCH] Remove the code of handling enable/disable self-start service + in Makefile.in + +Remove the handling of enable/disable sysstat.service self-start in Makefile.in. +The code will trigger below error when cross compiling with +'--enable-install-cron': +| if [ -x "/path/to/sysstat/11.7.1-r0/recipe-sysroot-native/usr/bin/systemctl" ]; then \ +| /path/to/sysstat/11.7.1-r0/recipe-sysroot-native/usr/bin/systemctl enable sysstat.service; \ +| fi +| Started /path/to/sysstat/11.7.1-r0/recipe-sysroot-native/usr/bin/systemctl enable sysstat.service +| Try to find location of sysstat.service... +| 'sysstat.service' couldn't be found; exiting with error + +It's better for user to enable/disable the service with +'systemctl enable/disable sysstat.service' + +Upstream-Status: Inappropriate [ embedded specific ] + +Signed-off-by: Haiqing Bai +--- + Makefile.in | 8 + 1 file changed, 8 deletions(-) + +diff --git a/Makefile.in b/Makefile.in +index edaea3f..2186155 100644 +--- a/Makefile.in b/Makefile.in +@@ -454,11 +454,6 @@ endif + fi \ + fi \ + fi +-ifeq ($(COPY_ONLY),n) +- if [ -x "$(SYSTEMCTL)" ]; then \ +- $(SYSTEMCTL) enable sysstat.service; \ +- fi +-endif + + uninstall_man: + ifeq ($(INSTALL_DOC),y) +@@ -541,9 +536,6 @@ ifeq ($(COPY_ONLY),n) + @echo "USER'S CRONTAB SAVED IN CURRENT DIRECTORY (USING .old SUFFIX)." ; \ + -su $(CRON_OWNER) -c "crontab -r" ; \ + fi +- if [ -x $(SYSTEMCTL) ]; then \ +- $(SYSTEMCTL) disable sysstat.service; \ +- fi + endif + if [ -n "$(SYSTEMD_UNIT_DIR)" -a -d $(DESTDIR)$(SYSTEMD_UNIT_DIR) ]; then \ + rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/sysstat.service; \ +-- +1.9.1 + diff --git a/meta/recipes-extended/sysstat/sysstat_11.7.1.bb b/meta/recipes-extended/sysstat/sysstat_11.7.1.bb index 86738e7..26be619 100644 --- a/meta/recipes-extended/sysstat/sysstat_11.7.1.bb +++ b/meta/recipes-extended/sysstat/sysstat_11.7.1.bb @@ -2,7 +2,8 @@ require sysstat.inc LIC_FILES_CHKSUM = "file://COPYING;md5=a23a74b3f4caf9616230789d94217acb" -SRC_URI += "file://0001-Include-needed-headers-explicitly.patch" +SRC_URI += "file://0001-Include-needed-headers-explicitly.patch \ + file://0001-Remove-the-code-of-handling-enable-disable-self-star.patch" SRC_URI[md5sum] = "bdcda7c9048c7c22fb1f30f75285d13d" SRC_URI[sha256sum] = "303a595b1af0330b183a0f1febfccf89f183b9575ae0562b91fdb876f3ef1feb" -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/3] cmake-native: Enable ccmake by default and depend on ncurses
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:
> > >
> > > >
> > > > Enable the building of the curses based ui for cmake. This depends on
> > > > ncurses.
> > >
> > > I think this is acceptable. It might also be useful for people wanting to
> > > use ccmake inside an SDK.
>
> Just to be clear, this change only affects cmake-native, the recipe
> for target/nativesdk is unchanged. Although interestingly the cmake
> (target/nativesdk) recipe already depends on ncurses (despite
> disabling ccmake).
>
> > >
> >
> > Adding dependencies do serialize builds and might have penalty on
> > build time, better is to turn this into a packageconfig
> > option and keep it disabled by default.
>
> I can rework this patch to make it a PACKAGECONFIG option. However the
> reason for enabling ccmake by default is due to the addition of the
> ccmake bbclass in this series, which relies on having ccmake available
> in the native sysroot. Having to override PACKAGECONFIG to use the
> ccmake class seemed broken (since it is not particularly a distro
> config).
>
> I could not find a good example of this sort of requirement for
> configuration for any other bbclass except for maybe
> gobject-introspection (which relies on qemu-native configured
> correctly to have linux-user for the target).
>
> Another approach I considered to have this working without requiring
> the user to setup PACKAGECONFIG would be to have a "ccmake-native"
> recipe which built the ccmake binary. But this seemed like it would be
> extra maintenance burden compared to this patch which has minimal
> build time overhead.
>
this seems fine, if the number of recipes needing this bbclass are far less than
one the needing cmake bbclass.
> Regards,
> Nathan
>
> >
> > > > Signed-off-by: Nathan Rossi
> > > > ---
> > > > This patch suggests enabling this in the cmake-native recipe, however
> > > > this
> > > > might be undesirable for bootstrapping reasons. Whilst ccmake is not
> > > > used
> > > > normally the added dependency on ncurses is likely required for other
> > > > parts
> > > > of the build so impact on build ordering and time should be relatively
> > > > minimal.
> > > >
> > > > Changes in v2:
> > > > - None
> > > > ---
> > > > meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++---
> > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > index fedcf3d4bd..b2952ee5f5 100644
> > > > --- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > +++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > @@ -1,7 +1,7 @@
> > > > require cmake.inc
> > > > inherit native
> > > >
> > > > -DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> > > > curl-native"
> > > > +DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native
> > > > curl-native ncurses-native"
> > > >
> > > > SRC_URI += "file://OEToolchainConfig.cmake \
> > > > file://environment.d-cmake.sh \ @@ -13,10 +13,9 @@ SRC_URI
> > > > +=
> > > > "file://OEToolchainConfig.cmake \ B = "${WORKDIR}/build"
> > > > do_configure[cleandirs] = "${B}"
> > > >
> > > > -# Disable ccmake since we don't depend on ncurses CMAKE_EXTRACONF =
> > > > "\
> > > > -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
> > > > --DBUILD_CursesDialog=0 \
> > > > +-DBUILD_CursesDialog=1 \
> > > > -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
> > > > -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
> > > > -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \
> > > > ---
> > > > 2.20.1
> > > > --
> > > > ___
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/3] cmake-native: Enable ccmake by default and depend on ncurses
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:
> > > >
> > > > >
> > > > > Enable the building of the curses based ui for cmake. This depends on
> > > > > ncurses.
> > > >
> > > > I think this is acceptable. It might also be useful for people wanting
> > > > to use ccmake inside an SDK.
> >
> > Just to be clear, this change only affects cmake-native, the recipe
> > for target/nativesdk is unchanged. Although interestingly the cmake
> > (target/nativesdk) recipe already depends on ncurses (despite
> > disabling ccmake).
> >
> > > >
> > >
> > > Adding dependencies do serialize builds and might have penalty on
> > > build time, better is to turn this into a packageconfig
> > > option and keep it disabled by default.
> >
> > I can rework this patch to make it a PACKAGECONFIG option. However the
> > reason for enabling ccmake by default is due to the addition of the
> > ccmake bbclass in this series, which relies on having ccmake available
> > in the native sysroot. Having to override PACKAGECONFIG to use the
> > ccmake class seemed broken (since it is not particularly a distro
> > config).
> >
> > I could not find a good example of this sort of requirement for
> > configuration for any other bbclass except for maybe
> > gobject-introspection (which relies on qemu-native configured
> > correctly to have linux-user for the target).
> >
> > Another approach I considered to have this working without requiring
> > the user to setup PACKAGECONFIG would be to have a "ccmake-native"
> > recipe which built the ccmake binary. But this seemed like it would be
> > extra maintenance burden compared to this patch which has minimal
> > build time overhead.
> >
>
> this seems fine, if the number of recipes needing this bbclass are far less
> than
> one the needing cmake bbclass.
Just to clarify, are you suggesting that making a ccmake-native recipe
would be fine? Or that requiring the PACKAGECONFIG setup would be
acceptable/preferred?
Thanks,
Nathan
>
> > Regards,
> > Nathan
> >
> > >
> > > > > Signed-off-by: Nathan Rossi
> > > > > ---
> > > > > This patch suggests enabling this in the cmake-native recipe, however
> > > > > this
> > > > > might be undesirable for bootstrapping reasons. Whilst ccmake is not
> > > > > used
> > > > > normally the added dependency on ncurses is likely required for other
> > > > > parts
> > > > > of the build so impact on build ordering and time should be relatively
> > > > > minimal.
> > > > >
> > > > > Changes in v2:
> > > > > - None
> > > > > ---
> > > > > meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++---
> > > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > > b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > > index fedcf3d4bd..b2952ee5f5 100644
> > > > > --- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > > +++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
> > > > > @@ -1,7 +1,7 @@
> > > > > require cmake.inc
> > > > > inherit native
> > > > >
> > > > > -DEPENDS += "bzip2-replacement-native expat-native xz-native
> > > > > zlib-native
> > > > > curl-native"
> > > > > +DEPENDS += "bzip2-replacement-native expat-native xz-native
> > > > > zlib-native
> > > > > curl-native ncurses-native"
> > > > >
> > > > > SRC_URI += "file://OEToolchainConfig.cmake \
> > > > > file://environment.d-cmake.sh \ @@ -13,10 +13,9 @@
> > > > > SRC_URI +=
> > > > > "file://OEToolchainConfig.cmake \ B = "${WORKDIR}/build"
> > > > > do_configure[cleandirs] = "${B}"
> > > > >
> > > > > -# Disable ccmake since we don't depend on ncurses CMAKE_EXTRACONF =
> > > > > "\
> > > > > -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
> > > > > --DBUILD_CursesDialog=0 \
> > > > > +-DBUILD_CursesDialog=1 \
> > > > > -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
> > > > > -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
> > > > > -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \
> > > > > ---
> > > > > 2.20.1
> > > > > --
> > > > > ___
> > > > > Openembedded-core mailing list
> > > > > Openembedded-core@lists.openembedded.org
> > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > > > --
> > > > ___
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libgcc: Create linux-musleabihf and linux-gnueabihf symlinks
When we have hard-float ABI enabled, certain tools e.g. llvm/clang
expects the hf version of tuples for crt files from libgcc, therefore
create a symlink to help the cause.
This makes clang work with hard-float defaults on target
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gcc/libgcc.inc | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/recipes-devtools/gcc/libgcc.inc
b/meta/recipes-devtools/gcc/libgcc.inc
index e4e0c48007..e008d14f36 100644
--- a/meta/recipes-devtools/gcc/libgcc.inc
+++ b/meta/recipes-devtools/gcc/libgcc.inc
@@ -11,6 +11,13 @@ do_install_append_class-target () {
esac
ln -s ${TARGET_SYS}
${D}${libdir}/${TARGET_ARCH}${TARGET_VENDOR}-$extra_target_os
fi
+ if [ -n "${@ bb.utils.contains('TUNE_CCARGS_MFLOAT', 'hard', 'hf', '',
d)}" ]; then
+ case "${TARGET_OS}" in
+ "linux-musleabi") extra_target_os="linux-musleabihf";;
+ "linux-gnueabi") extra_target_os="linux-gnueabihf";;
+ esac
+ ln -s ${TARGET_SYS}
${D}${libdir}/${TARGET_ARCH}${TARGET_VENDOR}-$extra_target_os
+ fi
}
PACKAGES = "\
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] asciidoc: disable xmllint check
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
"/build/tmp/work/x86_64-linux/asciidoc-native/8.6.9+py3-gitAUTOINC+618f6e6f6b-r0/git/doc/asciidoc.1.xml"
returned non-zero exit status 4
|
| Makefile:110: recipe for target 'doc/asciidoc.1' failed
Considering it's only used to check the xml format
of the doc file as doc/asciidoc.1.txt, so disable
xmllint check to fix the above issue.
Signed-off-by: Mingli Yu
---
meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb | 4 ++-
.../0001-Makefile.in-disable-xmllint-check.patch | 38 ++
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch
diff --git a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
index d0d1517..7e00b34 100644
--- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
+++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
@@ -8,7 +8,9 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
file://COPYRIGHT;md5=029ad5428ba5efa20176b396222d4069"
-SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https"
+SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https \
+ file://0001-Makefile.in-disable-xmllint-check.patch \
+"
SRCREV = "618f6e6f6b558ed1e5f2588cd60a5a6b4f881ca0"
PV .= "+py3-git${SRCPV}"
diff --git
a/meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch
b/meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch
new file mode 100644
index 000..4c0dd6d
--- /dev/null
+++
b/meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch
@@ -0,0 +1,38 @@
+From 242e58f16c129f5983d6b32d493619cc4f87703e Mon Sep 17 00:00:00 2001
+From: Mingli Yu
+Date: Thu, 4 Apr 2019 13:38:10 +0800
+Subject: [PATCH] Makefile.in: disable xmllint check
+
+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
"/build/tmp/work/x86_64-linux/asciidoc-native/8.6.9+py3-gitAUTOINC+618f6e6f6b-r0/git/doc/asciidoc.1.xml"
returned non-zero exit status 4
+|
+| Makefile:110: recipe for target 'doc/asciidoc.1' failed
+
+So disable xmllint check to fix the above issue.
+
+Upstream-Status: Inappropriate [oe build specific]
+
+Signed-off-by: Mingli Yu
+---
+ Makefile.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index ffba3b5..fb95fab 100644
+--- a/Makefile.in
b/Makefile.in
+@@ -107,7 +107,7 @@ $(DATATARGETS): % : %dir
+ $(INSTALL_DATA) $($@) $(DESTDIR)/$($<)/
+
+ $(manp): %.1 : %.1.txt
+- python3 a2x.py -f manpage $<
++ python3 a2x.py -L -f manpage $<
+
+ docs:
+ $(INSTALL) -d $(DESTDIR)/$(docdir)
+--
+2.7.4
+
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] ghostscript: Fix CVE-2019-3835 and CVE-2019-3838
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 master is preferred
to upgrade to a newer version when it's available instead of backporting
fixes.
Ovidiu
On Wed, 3 Apr 2019 at 13:39, Ovidiu Panait wrote:
It was found that the superexec operator was available in the internal
dictionary in ghostscript before 9.27. A specially crafted PostScript
file could use this flaw in order to, for example, have access to the
file system outside of the constrains imposed by -dSAFER.
It was found that the forceput operator could be extracted from the
DefineResource method in ghostscript before 9.27. A specially crafted
PostScript file could use this flaw in order to, for example, have
access to the file system outside of the constrains imposed by -dSAFER.
References:
https://nvd.nist.gov/vuln/detail/CVE-2019-3835
https://nvd.nist.gov/vuln/detail/CVE-2019-3838
Upstream patches:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=779664d
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e8acf6d
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2055917
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d683d1e
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ed9fcd9
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a82601e
Signed-off-by: Ovidiu Panait
---
.../ghostscript/CVE-2019-3835-0001.patch | 99 ++
.../ghostscript/CVE-2019-3835-0002.patch | 71 +
.../ghostscript/CVE-2019-3835-0003.patch | 295 ++
.../ghostscript/CVE-2019-3835-0004.patch | 167 ++
.../ghostscript/CVE-2019-3838-0001.patch | 34 ++
.../ghostscript/CVE-2019-3838-0002.patch | 30 ++
.../ghostscript/ghostscript_9.26.bb | 6 +
7 files changed, 702 insertions(+)
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0002.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0003.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0004.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3838-0001.patch
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3838-0002.patch
diff --git
a/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
new file mode 100644
index 00..30ce04a7b1
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-3835-0001.patch
@@ -0,0 +1,99 @@
+From ad3ad6b389653722507e588c5cb34d8731e49e89 Mon Sep 17 00:00:00 2001
+From: Chris Liddell
+Date: Mon, 26 Nov 2018 18:01:25 +
+Subject: [PATCH] Have gs_cet.ps run from gs_init.ps
+
+Previously gs_cet.ps was run on the command line, to set up the interpreter
+state so our output more closely matches the example output for the QL CET
+tests.
+
+Allow a -dCETMODE command line switch, which will cause gs_init.ps to run the
+file directly.
+
+This works better for gpdl as it means the changes are made in the intial
+interpreter state, rather than after initialisation is complete.
+
+This also means adding a definition of the default procedure for black
+generation and under color removal (rather it being defined in-line in
+.setdefaultbgucr
+
+Also, add a check so gs_cet.ps only runs once - if we try to run it a second
+time, we'll just skip over the file, flushing through to the end.
+
+CVE: CVE-2019-3835
+Upstream-Status: Backport [git://git.ghostscript.com/ghostpdl.git]
+
+Signed-off-by: Ovidiu Panait
+---
+ Resource/Init/gs_cet.ps | 11 ++-
+ Resource/Init/gs_init.ps | 13 -
+ 2 files changed, 22 insertions(+), 2 deletions(-)
+
+diff --git a/Resource/Init/gs_cet.ps b/Resource/Init/gs_cet.ps
+index d3e1686..75534bb 100644
+--- a/Resource/Init/gs_cet.ps
b/Resource/Init/gs_cet.ps
+@@ -1,6 +1,11 @@
+ %!PS
+ % Set defaults for Ghostscript to match Adobe CPSI behaviour for CET
+
++systemdict /product get (PhotoPRINT SE 5.0v2) readonly eq
++{
++ (%END GS_CET) .skipeof
++} if
++
+ % do this in the server level so it is persistent across jobs
+ //true 0 startjob not {
+ (*** Warning: CET startup is not in server default) = flush
+@@ -25,7 +30,9 @@ currentglobal //true setglobal
+
+ /UNROLLFORMS true def
+
+-{ } bind dup
++(%.defaultbgrucrproc) cvn { } bind def
++
++(%.defaultbgrucrproc) cvn load dup
+ setblackgeneration
+ setundercolorremoval
+ 0 array cvx readonly dup dup dup setcolortransfer
+@@ -109,3 +116,5 @@ userdict /.smoothness currentsmoothness put
+ % end of slightly nasty hack to give consistent cluster results
+
+ //false
