[OE-core] [OE-Core][master][PATCH v3 3/3] devtool: provide support for devtool menuconfig command
All packages that support the menuconfig task will be able to run
devtool menuconfig command. This would allow the user to modify the
current configure options and create a config fragment which can be
added to a recipe using devtool finish.
1. The patch checks if devtool menuconfig command is called for a valid
package.
2. It checks for oe-local-files dir within source and creates one if
needed, this directory is needed to store the final generated config
fragment so that devtool finish can update the recipe.
3. Menuconfig command is called for users to make necessary changes.
After saving the changes, diffconfig command is run to generate the
fragment.
Syntax:
devtool menuconfig
Ex: devtool menuconfig linux-yocto
The config fragment is saved as devtool-fragment.cfg within
oe-local-files dir.
Ex:
/sources/linux-yocto/oe-local-files/devtool-fragment.cfg
Run devtool finish to update the recipe by appending the config fragment
to SRC_URI and place a copy of the fragment within the layer where the
recipe resides.
Ex: devtool finish linux-yocto meta
[YOCTO #10416]
Signed-off-by: Sai Hari Chandana Kalluri
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
scripts/lib/devtool/menuconfig.py | 80 +++
scripts/lib/devtool/standard.py | 5 +++
2 files changed, 85 insertions(+)
create mode 100644 scripts/lib/devtool/menuconfig.py
diff --git a/scripts/lib/devtool/menuconfig.py
b/scripts/lib/devtool/menuconfig.py
new file mode 100644
index 000..f8a24aa
--- /dev/null
+++ b/scripts/lib/devtool/menuconfig.py
@@ -0,0 +1,80 @@
+# OpenEmbedded Development tool - menuconfig command plugin
+#
+# Copyright (C) 2018 Xilinx
+# Written by: Chandana Kalluri
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+"""Devtool menuconfig plugin"""
+
+import os
+import bb
+import logging
+import argparse
+import re
+import glob
+from devtool import setup_tinfoil, parse_recipe, DevtoolError, standard,
exec_build_env_command
+
+logger = logging.getLogger('devtool')
+
+def menuconfig(args, config, basepath, workspace):
+"""Entry point for the devtool 'menuconfig' subcommand"""
+
+rd = ""
+kconfigpath = ""
+pn_src = ""
+localfilesdir = ""
+workspace_dir = ""
+tinfoil = setup_tinfoil(basepath=basepath)
+try:
+ rd = parse_recipe(config, tinfoil, args.component, appends=True,
filter_workspace=False)
+ if not rd:
+ return 1
+
+ pn = rd.getVar('PN', True)
+ if pn not in workspace:
+ raise DevtoolError("Run devtool modify before calling menuconfig for
%s" %pn)
+
+ if not rd.getVarFlag('do_menuconfig','task'):
+ raise DevtoolError("This package does not support menuconfig option")
+
+ workspace_dir = os.path.join(basepath,'workspace/sources')
+ kconfigpath = rd.getVar('B')
+ pn_src = os.path.join(workspace_dir,pn)
+
+ #add check to see if oe_local_files exists or not
+ localfilesdir = os.path.join(pn_src,'oe-local-files')
+ if not os.path.exists(localfilesdir):
+ bb.utils.mkdirhier(localfilesdir)
+ #Add gitignore to ensure source tree is clean
+ gitignorefile = os.path.join(localfilesdir,'.gitignore')
+ with open(gitignorefile, 'w') as f:
+ f.write('# Ignore local files, by default. Remove this file
if you want to commit the directory to Git\n')
+ f.write('*\n')
+
+finally:
+ tinfoil.shutdown()
+
+logger.info('Launching menuconfig')
+exec_build_env_command(config.init_path, basepath, 'bitbake -c menuconfig
%s' % pn, watch=True)
+fragment = os.path.join(localfilesdir, 'devtool-fragment.cfg')
+res = standard._create_kconfig_diff(pn_src,rd,fragment)
+
+return 0
+
+def register_commands(subparsers, context):
+"""register devtool subcommands from this plugin"""
+parser_menuconfig = subparsers.add_parser('menuconfig',help='Alter
build-time configuration for a recipe', description='Launches the make
menuconfig command(for recipes where do_menuconfig is available), allowing
users to make changes to the build-time configuration. Creates a config
fragment corresponding to changes made.', group='advanced')
+parser_menuconfig.add_argument('component', help='component to alter
config')
+
Re: [OE-core] [PATCH 1/2] llvm: doesn't actually need pythonnative
On Wed, Mar 27, 2019 at 4:07 PM Ross Burton wrote:
>
> LLVM doesn't actually need pythonnative, the host Python2 is sufficient but
> cmake's executable searching currently isn't reliable in cross-compilations.
>
> Convince cmake by setting PYTHON_EXECUTABLE to point at python2 in the
> HOSTTOOLS
> directory. Note that currently LLVM *needs* python2 currently:
>
this should be ok
> https://github.com/llvm-mirror/llvm/blob/master/CMakeLists.txt#L670
>
> Signed-off-by: Ross Burton
> ---
> meta/recipes-devtools/llvm/llvm_git.bb | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/llvm/llvm_git.bb
> b/meta/recipes-devtools/llvm/llvm_git.bb
> index d2ea927651d..31abadcace5 100644
> --- a/meta/recipes-devtools/llvm/llvm_git.bb
> +++ b/meta/recipes-devtools/llvm/llvm_git.bb
> @@ -12,7 +12,7 @@ DEPENDS = "libffi libxml2 zlib ninja-native llvm-native"
>
> RDEPENDS_${PN}_append_class-target = " ncurses-terminfo"
>
> -inherit perlnative pythonnative cmake pkgconfig
> +inherit perlnative cmake pkgconfig
>
> PROVIDES += "llvm${PV}"
>
> @@ -74,6 +74,7 @@ EXTRA_OECMAKE += "-DLLVM_ENABLE_ASSERTIONS=OFF \
>-DFFI_INCLUDE_DIR=$(pkg-config --variable=includedir
> libffi) \
>-DLLVM_OPTIMIZED_TABLEGEN=ON \
>-DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS}' \
> + -DPYTHON_EXECUTABLE=${HOSTTOOLS_DIR}/python2 \
>-G Ninja"
>
> EXTRA_OECMAKE_append_class-target = "\
> --
> 2.11.0
>
> --
> ___
> 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] wic/bootimg-efi.py: add new source parameter "initrd_rename"
On Fri, Mar 29, 2019 at 12:07:59AM +, Liu, Yongxin wrote:
> > -Original Message-
> > From: Tom Rini [mailto:tr...@konsulko.com]
> > Sent: Thursday, March 28, 2019 21:59
> > To: Liu, Yongxin
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH] wic/bootimg-efi.py: add new source
> > parameter "initrd_rename"
> >
> > On Wed, Mar 27, 2019 at 06:37:42PM +0800, Yongxin Liu wrote:
> >
> > > When using initrd in bootloader configuration file, we may want the
> > > name of initrd to be fixed. However, the actual name of initrd may
> > > change and depend on distro/machine's name. "initrd_rename"
> > > gives user a chance to rename initrd in final wic image.
> > >
> > > Signed-off-by: Yongxin Liu
> >
> > I'm not nak'ing this patch, but I've long fixed this by just not using
> > the "efi" plugin to make an EFI system and instead IMAGE_BOOT_FILES to
> > say what goes where. There's a lot of cases bootimg-efi doesn't cover
> > but are handled easily with IMAGE_BOOT_FILES.
>
>
> Thanks Tom for your input.
>
> What I want to do is to copy
> "${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
> to EFI boot partition and rename it to be "initrd", like
>
>/boot
> ├── bzImage
> ├── EFI
> │ └── BOOT
> │ ├── bootx64.efi
> │ └── grub.cfg
> ├── initrd
>
> "IMAGE_BOOT_FILES" is good to provide such function.
> How about porting "IMAGE_BOOT_FILES" to bootimg-efi.py?
The only thing that bootimg-efi.py provides, in my mind, is
auto-generation of a simplistic grub/systemd-boot config file. I also
don't ever want that and just list the config files under
IMAGE_BOOT_FILES as well. I really think we could drop bootimg-efi.py
aside from the case where we don't have a config file for some reason
(Stand-alone wic?)
--
Tom
signature.asc
Description: PGP signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf: don't build api-documentation for native and nativesdk
Ignore this: totally breaks. I might add a better comment instead. Ross On Thu, 28 Mar 2019 at 23:30, Ross Burton wrote: > > DISTRO_FEATURES for native and nativesdk is filtered to contain a subset of > the > features for the target DISTRO_FEATURES. api-documentation was a feature that > was allowed into the native/nativesdk features if it was in the target, but > having API documentation for native recipes isn't really useful. > > As building this documentation takes time, remove it from native/nativesdk > builds so that we only build the api-documentation for target recipes. > > Signed-off-by: Ross Burton > --- > meta/conf/bitbake.conf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > index 7f8b043cc45..86a9e4b8281 100644 > --- a/meta/conf/bitbake.conf > +++ b/meta/conf/bitbake.conf > @@ -833,8 +833,8 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" > > # Normally target distro features will not be applied to native builds: > # Native distro features on this list will use the target feature value > -DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" > -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation" > +DISTRO_FEATURES_FILTER_NATIVE ?= "" > +DISTRO_FEATURES_FILTER_NATIVESDK ?= "" > > DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 > gobject-introspection-data ldconfig" > MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" > -- > 2.11.0 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] wic/bootimg-efi.py: add new source parameter "initrd_rename"
> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Thursday, March 28, 2019 21:59
> To: Liu, Yongxin
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] wic/bootimg-efi.py: add new source
> parameter "initrd_rename"
>
> On Wed, Mar 27, 2019 at 06:37:42PM +0800, Yongxin Liu wrote:
>
> > When using initrd in bootloader configuration file, we may want the
> > name of initrd to be fixed. However, the actual name of initrd may
> > change and depend on distro/machine's name. "initrd_rename"
> > gives user a chance to rename initrd in final wic image.
> >
> > Signed-off-by: Yongxin Liu
>
> I'm not nak'ing this patch, but I've long fixed this by just not using
> the "efi" plugin to make an EFI system and instead IMAGE_BOOT_FILES to
> say what goes where. There's a lot of cases bootimg-efi doesn't cover
> but are handled easily with IMAGE_BOOT_FILES.
Thanks Tom for your input.
What I want to do is to copy
"${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
to EFI boot partition and rename it to be "initrd", like
/boot
├── bzImage
├── EFI
│ └── BOOT
│ ├── bootx64.efi
│ └── grub.cfg
├── initrd
"IMAGE_BOOT_FILES" is good to provide such function.
How about porting "IMAGE_BOOT_FILES" to bootimg-efi.py?
Thanks,
Yongxin
>
> --
> Tom
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: don't build api-documentation for native and nativesdk
DISTRO_FEATURES for native and nativesdk is filtered to contain a subset of the features for the target DISTRO_FEATURES. api-documentation was a feature that was allowed into the native/nativesdk features if it was in the target, but having API documentation for native recipes isn't really useful. As building this documentation takes time, remove it from native/nativesdk builds so that we only build the api-documentation for target recipes. Signed-off-by: Ross Burton --- meta/conf/bitbake.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 7f8b043cc45..86a9e4b8281 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -833,8 +833,8 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value -DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation" +DISTRO_FEATURES_FILTER_NATIVE ?= "" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sqlite3: fix CVE-2019-9936 and CVE-2019-9937
Signed-off-by: Ross Burton
---
.../sqlite/sqlite3/CVE-2019-9936.patch | 28 +++
.../sqlite/sqlite3/CVE-2019-9937.patch | 187 +
meta/recipes-support/sqlite/sqlite3_3.27.2.bb | 2 +
3 files changed, 217 insertions(+)
create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-9936.patch
create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-9937.patch
diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-9936.patch
b/meta/recipes-support/sqlite/sqlite3/CVE-2019-9936.patch
new file mode 100644
index 000..1b907b9d4dd
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-9936.patch
@@ -0,0 +1,28 @@
+Running fts5 prefix queries inside a transaction could trigger a heap-based
+buffer over-read in fts5HashEntrySort in sqlite3.c, which may lead to an
+information leak.
+
+CVE: CVE-2019-9936
+Upstream-Status: Backport
[https://sqlite.org/src/vpatch?from=45c73deb440496e8=b3fa58dd7403dbd4]
+Signed-off-by: Ross Burton
+---
+ sqlite3.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 4729f45..65527d8 100644
+--- a/sqlite3.c
b/sqlite3.c
+@@ -207759,7 +207759,9 @@ static int fts5HashEntrySort(
+ for(iSlot=0; iSlotnSlot; iSlot++){
+ Fts5HashEntry *pIter;
+ for(pIter=pHash->aSlot[iSlot]; pIter; pIter=pIter->pHashNext){
+- if( pTerm==0 || 0==memcmp(fts5EntryKey(pIter), pTerm, nTerm) ){
++ if( pTerm==0
++ || (pIter->nKey+1>=nTerm && 0==memcmp(fts5EntryKey(pIter), pTerm,
nTerm))
++ ){
+ Fts5HashEntry *pEntry = pIter;
+ pEntry->pScanNext = 0;
+ for(i=0; ap[i]; i++){
+--
+2.20.1
diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-9937.patch
b/meta/recipes-support/sqlite/sqlite3/CVE-2019-9937.patch
new file mode 100644
index 000..baa5666ddaa
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-9937.patch
@@ -0,0 +1,187 @@
+Interleaving reads and writes in a single transaction with an fts5 virtual
table
+will lead to a NULL Pointer Dereference in fts5ChunkIterate in sqlite3.c.
+
+CVE: CVE-2019-9937
+Upstream-Status: Backport
[https://sqlite.org/src/vpatch?from=c2f50aa4e7bad882=45c73deb440496e8]
+Signed-off-by: Ross Burton
+
+---
+ sqlite3.c | 83 ++-
+ 1 file changed, 57 insertions(+), 26 deletions(-)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 65527d8..b1a8799 100644
+--- a/sqlite3.c
b/sqlite3.c
+@@ -200668,8 +200668,9 @@ static void sqlite3Fts5HashClear(Fts5Hash*);
+
+ static int sqlite3Fts5HashQuery(
+ Fts5Hash*, /* Hash table to query */
++ int nPre,
+ const char *pTerm, int nTerm, /* Query term */
+- const u8 **ppDoclist, /* OUT: Pointer to doclist for pTerm */
++ void **ppObj, /* OUT: Pointer to doclist for pTerm
*/
+ int *pnDoclist /* OUT: Size of doclist in bytes */
+ );
+
+@@ -207501,19 +207502,25 @@ static int fts5HashResize(Fts5Hash *pHash){
+ return SQLITE_OK;
+ }
+
+-static void fts5HashAddPoslistSize(Fts5Hash *pHash, Fts5HashEntry *p){
++static int fts5HashAddPoslistSize(
++ Fts5Hash *pHash,
++ Fts5HashEntry *p,
++ Fts5HashEntry *p2
++){
++ int nRet = 0;
+ if( p->iSzPoslist ){
+-u8 *pPtr = (u8*)p;
++u8 *pPtr = p2 ? (u8*)p2 : (u8*)p;
++int nData = p->nData;
+ if( pHash->eDetail==FTS5_DETAIL_NONE ){
+- assert( p->nData==p->iSzPoslist );
++ assert( nData==p->iSzPosList );
+ if( p->bDel ){
+-pPtr[p->nData++] = 0x00;
++pPtr[nData++] = 0x00;
+ if( p->bContent ){
+- pPtr[p->nData++] = 0x00;
++ pPtr[nData++] = 0x00;
+ }
+ }
+ }else{
+- int nSz = (p->nData - p->iSzPoslist - 1); /* Size in bytes */
++ int nSz = (nData - p->iSzPoslist - 1); /* Size in bytes */
+ int nPos = nSz*2 + p->bDel; /* Value of nPos field
*/
+
+ assert( p->bDel==0 || p->bDel==1 );
+@@ -207523,14 +207530,19 @@ static void fts5HashAddPoslistSize(Fts5Hash
*pHash, Fts5HashEntry *p){
+ int nByte = sqlite3Fts5GetVarintLen((u32)nPos);
+ memmove([p->iSzPoslist + nByte], [p->iSzPoslist + 1], nSz);
+ sqlite3Fts5PutVarint([p->iSzPoslist], nPos);
+-p->nData += (nByte-1);
++nData += (nByte-1);
+ }
+ }
+
+-p->iSzPoslist = 0;
+-p->bDel = 0;
+-p->bContent = 0;
++nRet = nData - p->nData;
++if( p2 == 0 ){
++ p->iSzPoslist = 0;
++ p->bDel = 0;
++ p->bContent = 0;
++ p->nData = nData;
++}
+ }
++ return nRet;
+ }
+
+ /*
+@@ -207642,7 +207654,7 @@ static int sqlite3Fts5HashWrite(
+ /* If this is a new rowid, append the 4-byte size field for the previous
+ ** entry, and the new rowid for this entry. */
+ if( iRowid!=p->iRowid ){
+-fts5HashAddPoslistSize(pHash, p);
++fts5HashAddPoslistSize(pHash, p, 0);
+ p->nData +=
[OE-core] [PATCH 1/2] meta-yocto-bsp: clean up machine config files
Beautify the machine config files by making the names and descriptions more uniform and verbose Signed-off-by: Jon Mason --- meta-yocto-bsp/conf/machine/edgerouter.conf| 2 +- meta-yocto-bsp/conf/machine/genericx86-64.conf | 5 ++--- meta-yocto-bsp/conf/machine/genericx86.conf| 5 ++--- meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 3 ++- 4 files changed, 7 insertions(+), 8 deletions(-) diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf b/meta-yocto-bsp/conf/machine/edgerouter.conf index 78c87f2f87..88592dbc85 100644 --- a/meta-yocto-bsp/conf/machine/edgerouter.conf +++ b/meta-yocto-bsp/conf/machine/edgerouter.conf @@ -1,6 +1,6 @@ #@TYPE: Machine #@NAME: Edgerouter -#@DESCRIPTION: Edgerouter +#@DESCRIPTION: Machine configuration for a generic edgerouter require conf/machine/include/tune-mips64.inc diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf b/meta-yocto-bsp/conf/machine/genericx86-64.conf index 12f7c0d200..c489462dca 100644 --- a/meta-yocto-bsp/conf/machine/genericx86-64.conf +++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf @@ -1,7 +1,6 @@ #@TYPE: Machine -#@NAME: Generic X86_64. - -#@DESCRIPTION: Machine configuration for generic X86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. +#@NAME: Generic x86_64 +#@DESCRIPTION: Machine configuration for generic x86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. DEFAULTTUNE ?= "core2-64" require conf/machine/include/tune-core2.inc diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf index 798b62ec2b..9929d2788a 100644 --- a/meta-yocto-bsp/conf/machine/genericx86.conf +++ b/meta-yocto-bsp/conf/machine/genericx86.conf @@ -1,7 +1,6 @@ #@TYPE: Machine -#@NAME: Generic X86. - -#@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. +#@NAME: Generic x86 +#@DESCRIPTION: Machine configuration for generic x86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. DEFAULTTUNE ?= "core2-32" require conf/machine/include/tune-core2.inc diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf index 54a34be3aa..e2dce56738 100644 --- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf +++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf @@ -1,5 +1,6 @@ #@TYPE: Machine -#@DESCRIPTION: Machine configuration for running +#@NAME: Freescale MPC8315E-RDB +#@DESCRIPTION: Machine configuration for Freescale MPC8315E-RDB TARGET_FPU = "" -- 2.17.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] machine: clean up config files
Beautify the machine config files by making the names and descriptions
more uniform and verbose
Signed-off-by: Jon Mason
---
meta/conf/machine/qemuarm.conf| 4 ++--
meta/conf/machine/qemuarm64.conf | 4 ++--
meta/conf/machine/qemuarmv5.conf | 6 +++---
meta/conf/machine/qemumips.conf | 4 ++--
meta/conf/machine/qemumips64.conf | 4 ++--
meta/conf/machine/qemuppc.conf| 4 ++--
meta/conf/machine/qemux86-64.conf | 4 ++--
meta/conf/machine/qemux86.conf| 4 ++--
8 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
index 9555046189..0a2c995312 100644
--- a/meta/conf/machine/qemuarm.conf
+++ b/meta/conf/machine/qemuarm.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: generic Arm Cortex-A15 machine
-#@DESCRIPTION: Machine configuration for running a generic armv7
+#@NAME: QEMU Arm Cortex-A15 machine
+#@DESCRIPTION: Machine configuration for running an ARMv7 system on QEMU
require conf/machine/include/tune-cortexa15.inc
require conf/machine/include/qemu.inc
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 22f6cb742b..5c8aac1511 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: generic armv8 machine
-#@DESCRIPTION: Machine configuration for running a generic armv8
+#@NAME: QEMU ARMv8 machine
+#@DESCRIPTION: Machine configuration for running an ARMv8 system on QEMU
require conf/machine/include/arm/arch-armv8a.inc
require conf/machine/include/qemu.inc
diff --git a/meta/conf/machine/qemuarmv5.conf b/meta/conf/machine/qemuarmv5.conf
index e3948a25da..1c21d3342d 100644
--- a/meta/conf/machine/qemuarmv5.conf
+++ b/meta/conf/machine/qemuarmv5.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: arm_versatile_926ejs
-#@DESCRIPTION: arm_versatile_926ejs
+#@NAME: QEMU ARM9 machine
+#@DESCRIPTION: Machine configuration for running an ARMv5 system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-arm926ejs.inc
@@ -20,4 +20,4 @@ QB_OPT_APPEND += "-object
rng-random,filename=/dev/urandom,id=rng0 -device virti
PREFERRED_VERSION_linux-yocto ??= "5.0%"
QB_DTB = "${@oe.utils.version_less_or_equal('PREFERRED_VERSION_linux-yocto',
'4.7', '', 'zImage-versatile-pb.dtb', d)}"
-KMACHINE_qemuarmv5 = "qemuarm"
\ No newline at end of file
+KMACHINE_qemuarmv5 = "qemuarm"
diff --git a/meta/conf/machine/qemumips.conf b/meta/conf/machine/qemumips.conf
index a60f67aa87..48d9f41d9d 100644
--- a/meta/conf/machine/qemumips.conf
+++ b/meta/conf/machine/qemumips.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: mti_malta32_be MIPS
-#@DESCRIPTION: mti_malta32_be
+#@NAME: QEMU MIPS32 machine
+#@DESCRIPTION: Machine configuration for running a MIPS system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-mips32r2.inc
diff --git a/meta/conf/machine/qemumips64.conf
b/meta/conf/machine/qemumips64.conf
index 970c0ce7ae..1872e7b62d 100644
--- a/meta/conf/machine/qemumips64.conf
+++ b/meta/conf/machine/qemumips64.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: mti-malta64-be MIPS64
-#@DESCRIPTION: mti-malta64-be
+#@NAME: QEMU MIPS64 machine
+#@DESCRIPTION: Machine configuration for running a MIPS64 system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-mips64r2.inc
diff --git a/meta/conf/machine/qemuppc.conf b/meta/conf/machine/qemuppc.conf
index 743d26170e..bd88eeb12a 100644
--- a/meta/conf/machine/qemuppc.conf
+++ b/meta/conf/machine/qemuppc.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: qemu PPC Emulator setup
-#@DESCRIPTION: Machine configuration for running an PPC system under qemu
emulation
+#@NAME: QEMU PPC machine
+#@DESCRIPTION: Machine configuration for running a PPC system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-ppc7400.inc
diff --git a/meta/conf/machine/qemux86-64.conf
b/meta/conf/machine/qemux86-64.conf
index 9966d1a04c..383e3bd6f3 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: common_pc
-#@DESCRIPTION: Machine configuration for running a common x86
+#@NAME: QEMU x86-64 machine
+#@DESCRIPTION: Machine configuration for running an x86-64 system on QEMU
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index e78fb6e87b..ae5187cbd5 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: common_pc
-#@DESCRIPTION: Machine configuration for running a common x86
+#@NAME: QEMU x86 machine
+#@DESCRIPTION: Machine configuration for running an x86 system on QEMU
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
--
2.17.2
--
___
[OE-core] [PATCH 0/2] clean up machine config files
General clean-up of the machine config files present in Yocto. Since this encompasses files that would natively be in the oe-core and meta-yocto-bsp repositories, I split them into 2 commits. However, since they are similar, I sent them in the same email thread. I hope this is acceptable. Jon Mason (2): meta-yocto-bsp: clean up machine config files machine: clean up config files meta-yocto-bsp/conf/machine/edgerouter.conf| 2 +- meta-yocto-bsp/conf/machine/genericx86-64.conf | 5 ++--- meta-yocto-bsp/conf/machine/genericx86.conf| 5 ++--- meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 3 ++- meta/conf/machine/qemuarm.conf | 4 ++-- meta/conf/machine/qemuarm64.conf | 4 ++-- meta/conf/machine/qemuarmv5.conf | 6 +++--- meta/conf/machine/qemumips.conf| 4 ++-- meta/conf/machine/qemumips64.conf | 4 ++-- meta/conf/machine/qemuppc.conf | 4 ++-- meta/conf/machine/qemux86-64.conf | 4 ++-- meta/conf/machine/qemux86.conf | 4 ++-- 12 files changed, 24 insertions(+), 25 deletions(-) -- 2.17.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] ninja: upate to 1.9.0
doxygen still fails
https://errors.yoctoproject.org/Errors/Details/234762/
On Sat, Mar 23, 2019 at 9:39 AM Oleksandr Kravchuk
wrote:
>
> Signed-off-by: Oleksandr Kravchuk
> ---
> .../ninja/ninja/fix-musl.patch| 39 +++
> .../ninja/{ninja_1.8.2.bb => ninja_1.9.0.bb} | 6 ++-
> 2 files changed, 43 insertions(+), 2 deletions(-)
> create mode 100644 meta/recipes-devtools/ninja/ninja/fix-musl.patch
> rename meta/recipes-devtools/ninja/{ninja_1.8.2.bb => ninja_1.9.0.bb} (87%)
>
> diff --git a/meta/recipes-devtools/ninja/ninja/fix-musl.patch
> b/meta/recipes-devtools/ninja/ninja/fix-musl.patch
> new file mode 100644
> index 00..543d4f1c48
> --- /dev/null
> +++ b/meta/recipes-devtools/ninja/ninja/fix-musl.patch
> @@ -0,0 +1,39 @@
> +2ff54ad7478a90bd75c91e434236a Mon Sep 17 00:00:00 2001
> +From: makepost
> +Date: Mon, 24 Dec 2018 03:13:16 +0200
> +Subject: [PATCH] Use st_mtim if st_mtime is macro, fix #1510
> +
> +In POSIX.1-2008, sys_stat has a st_mtim member and a st_mtime backward
> +compatibility macro. Should help avoid hardcoding platform detection.
> +---
> + src/disk_interface.cc | 14 --
> + 1 file changed, 4 insertions(+), 10 deletions(-)
> +
> +diff --git a/src/disk_interface.cc b/src/disk_interface.cc
> +index d4c2fb087..dc297c449 100644
> +--- src/disk_interface.cc
> /src/disk_interface.cc
> +@@ -202,19 +202,13 @@ TimeStamp RealDiskInterface::Stat(const string& path,
> string* err) const {
> + // that it doesn't exist.
> + if (st.st_mtime == 0)
> + return 1;
> +-#if defined(__APPLE__) && !defined(_POSIX_C_SOURCE)
> ++#if defined(_AIX)
> ++ return (int64_t)st.st_mtime * 10LL + st.st_mtime_n;
> ++#elif defined(__APPLE__)
> + return ((int64_t)st.st_mtimespec.tv_sec * 10LL +
> + st.st_mtimespec.tv_nsec);
> +-#elif (_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700 ||
> defined(_BSD_SOURCE) || defined(_SVID_SOURCE) || \
> +- defined(__BIONIC__) || (defined (__SVR4) && defined (__sun)) ||
> defined(__FreeBSD__))
> +- // For glibc, see "Timestamp files" in the Notes of
> http://www.kernel.org/doc/man-pages/online/pages/man2/stat.2.html
> +- // newlib, uClibc and musl follow the kernel (or Cygwin) headers and
> define the right macro values above.
> +- // For bsd, see
> https://github.com/freebsd/freebsd/blob/master/sys/sys/stat.h and similar
> +- // For bionic, C and POSIX API is always enabled.
> +- // For solaris, see
> https://docs.oracle.com/cd/E88353_01/html/E37841/stat-2.html.
> ++#elif defined(st_mtime) // A macro, so we're likely on modern POSIX.
> + return (int64_t)st.st_mtim.tv_sec * 10LL + st.st_mtim.tv_nsec;
> +-#elif defined(_AIX)
> +- return (int64_t)st.st_mtime * 10LL + st.st_mtime_n;
> + #else
> + return (int64_t)st.st_mtime * 10LL + st.st_mtimensec;
> + #endif
> diff --git a/meta/recipes-devtools/ninja/ninja_1.8.2.bb
> b/meta/recipes-devtools/ninja/ninja_1.9.0.bb
> similarity index 87%
> rename from meta/recipes-devtools/ninja/ninja_1.8.2.bb
> rename to meta/recipes-devtools/ninja/ninja_1.9.0.bb
> index c6fcfef3dd..1b06328961 100644
> --- a/meta/recipes-devtools/ninja/ninja_1.8.2.bb
> +++ b/meta/recipes-devtools/ninja/ninja_1.9.0.bb
> @@ -5,9 +5,11 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
>
> DEPENDS = "re2c-native ninja-native"
>
> -SRCREV = "253e94c1fa511704baeb61cf69995bbf09ba435e"
> +SRCREV = "b25c08bda4949192c69cea4cee057887341a2ffc"
>
> -SRC_URI = "git://github.com/ninja-build/ninja.git;branch=release"
> +SRC_URI = "git://github.com/ninja-build/ninja.git;branch=release \
> + file://fix-musl.patch \
> +"
> UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
>
> S = "${WORKDIR}/git"
> --
> 2.17.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] [PATCH] gdk-pixbuf:upgrade 2.38.0 -> 2.38.1
On Thu, 28 Mar 2019 at 03:33, Zang Ruochen wrote: > -Upgrade from gdk-pixbuf_2.38.0.bb to gdk-pixbuf_2.38.1.bb. > > -Delete > gdk-pixbuf/0001-Fix-a-couple-of-decisions-around-cross-compilation.patch > beacuse this patch has been fixed. > > -Delete > gdk-pixbuf/0001-loaders.cache-depend-on-loaders-being-fully-build.patch > beacuse this patch has been fixed. packages/corei7-64-poky-linux/gdk-pixbuf/gdk-pixbuf-bin: FILELIST: removed "/usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer /usr/bin/gdk-pixbuf-thumbnailer" Why? packages/corei7-64-poky-linux/gdk-pixbuf/gdk-pixbuf-dev: FILELIST: removed "/usr/bin/gdk-pixbuf-print-mime-types" Why? packages/corei7-64-poky-linux/gdk-pixbuf/gdk-pixbuf-ptest: PKGSIZE changed from 17746564 to 52 (-100%) packages/corei7-64-poky-linux/gdk-pixbuf/gdk-pixbuf-ptest: FILELIST: removed "/usr/libexec/installed-tests/gdk-pixbuf/large.png /usr/libexec/installed-tests/gdk-pixbuf/pixbuf-stream /usr/libexec/installed-tests/gdk-pixbuf/aero.gif /usr/libexec/installed-tests/gdk-pixbuf/test-images/reftests/tga/gtk-logo-gray-8bpp-top-right.tga.ref.png /usr/share/installed-tests/gdk-pixbuf/pixbuf-jpeg.test /usr/libexec/installed-tests/gdk-pixbuf/test-images/reftests/tga/gtk-logo-24bpp-top-right.tga.ref.png /usr/share/installed-tests/gdk-pixbuf/pixbuf-randomly-modified.test /usr/libexec/installed-tests/gdk-pixbuf/test-images/reftests/tga/gtk-logo-cmap.ref.png /usr/libexec/installed-tests/gdk-pixbuf/test-images/reftests/tga/gtk-logo-rle-24bpp-bottom-right.tga /usr/libexec/installed-tests/gdk-pixbuf/bug775229.pixdata /usr/libexec/installed-tests/gdk-pixbuf/test-images/reftests/tga/gtk-logo-cmap-rle-8bpp-top-right.tga.ref.png /usr/libexec/installed-tests/gdk-pixbuf/test-images/reftests/bug696331.png ... Where's the test suite gone? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] binutils: set CVE_VERSION
On Thu, Mar 28, 2019 at 02:41:05PM +, Ross Burton wrote: > PV is 2.32.0 even though the actual release upstream is 2.32. To a human this > is insignificant, but to automated tooling it matters. Specifically, > cve-check-tool can't identify CVEs that are in 2.32. > > Set CVE_VERSION for now, which should be removed when PV and the upstream > version match again. > > Signed-off-by: Ross Burton Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, Mar 28, 2019 at 02:38:40PM +, Burton, Ross wrote: > On Thu, 28 Mar 2019 at 14:25, Tom Rini wrote: > > Bumping PE is what this is for too, to not break package feeds after > > we've done something wrong in PV. So lets bump PE and not break feeds. > > Especially since this is so that CVE check starts to see and correctly > > complain about issues that will result in "lets move this from master to > > ..." and so break feeds. > > Bumping PE is a nuclear-armed hammer when setting CVE_VERSION="2.32" > is sufficient and will go away when we upgrade to 2.32.1 onwards. So long as we don't break package feeds, OK. Thanks! -- 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] binutils: set CVE_VERSION
PV is 2.32.0 even though the actual release upstream is 2.32. To a human this
is insignificant, but to automated tooling it matters. Specifically,
cve-check-tool can't identify CVEs that are in 2.32.
Set CVE_VERSION for now, which should be removed when PV and the upstream
version match again.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/binutils/binutils-2.32.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 15406441241..5d0c16b13ec 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -20,6 +20,7 @@ def binutils_branch_version(d):
# correctly set to match the upstream version tag).
UPSTREAM_VERSION_UNKNOWN = "1"
PV = "2.32.0"
+CVE_VERSION = "2.32"
BINUPV = "${@binutils_branch_version(d)}"
#BRANCH = "binutils-${BINUPV}-branch"
BRANCH ?= "binutils-2_32-branch"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] glibc broken when linked with gold Was: [oe] State of OE World, 2019-03-16
On Wed, Mar 27, 2019 at 10:08:32PM -0700, Khem Raj wrote: > On Wed, Mar 27, 2019 at 3:32 PM Martin Jansa wrote: > > > > On Wed, Mar 27, 2019 at 09:39:07PM +0100, Martin Jansa wrote: > > > On Wed, Mar 27, 2019 at 05:35:07PM +0100, Martin Jansa wrote: > > > > On Wed, Mar 27, 2019 at 05:17:54PM +0100, Martin Jansa wrote: > > > > > On Sun, Mar 17, 2019 at 08:26:37AM -0700, Khem Raj wrote: > > > > > > http://www.openembedded.org/wiki/Bitbake_World_Status > > > > > > > > > > > > == Failed tasks 2019-03-16 == > > > > > > > > > > > > INFO: jenkins-job.sh-1.8.45 Complete log available at > > > > > > http://logs.nslu2-linux.org/buildlogs/oe/world/warrior/log.report.20190317_082308.log > > > > > > > > > > > > * > > > > > > sources/openembedded-core/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.58.3.bb:do_compile > > > > > > > > > > I was hit by this one as well on some arm targets. > > > > > > > > > > http://logs.nslu2-linux.org/buildlogs/oe/world/warrior/log.world.qemuarm.20190321_215508.log/bitbake.log > > > > > > > > > > shows that it's actually from qemu-arm segfault inside > > > > > g-ir-scanner-qemuwrapper > > > > > > > > > > | qemu: uncaught target signal 11 (Segmentation fault) - core dumped > > > > > | > > > > > /home/jenkins/oe/world/yoe/build/tmpfs/work/armv7vet2hf-neon-yoe-linux-gnueabi/gobject-introspection/1.58.3-r0/build/g-ir-scanner-qemuwrapper: > > > > > line 6: 1959 Segmentation fault (core dumped) PSEUDO_UNLOAD=1 > > > > > qemu-arm -r 3.2.0 -L > > > > > /home/jenkins/oe/world/yoe/build/tmpfs/work/armv7vet2hf-neon-yoe-linux-gnueabi/gobject-introspection/1.58.3-r0/recipe-sysroot > > > > > -E > > > > > LD_LIBRARY_PATH=$GIR_EXTRA_LIBS_PATH:.libs:/home/jenkins/oe/world/yoe/build/tmpfs/work/armv7vet2hf-neon-yoe-linux-gnueabi/gobject-introspection/1.58.3-r0/recipe-sysroot//usr/lib:/home/jenkins/oe/world/yoe/build/tmpfs/work/armv7vet2hf-neon-yoe-linux-gnueabi/gobject-introspection/1.58.3-r0/recipe-sysroot//lib > > > > > "$@" > > > > > > > > > > The interesting part is that this happens only when glibc is built > > > > > with gold enabled. > > > > > > > > > > I've put a bit more details in temporary work-around here: > > > > > https://github.com/shr-distribution/meta-smartphone/commit/8f06eb355ead85464b1a1bbaa82584504df15743 > > > > > > > > > > I'm comparing qemuarm glibc build with bfd and gold to see if there > > > > > is some > > > > > significant difference which might cause this and I plan to flash > > > > > some small > > > > > image on my targets to see if libc is broken in runtime as well or > > > > > only when > > > > > running inside qemu-arm. > > > > > > > > > > Is anyone else seeing this as well? > > > > > > > > Checking older world status on the wiki shows that this issue was > > > > introduced somewhere around christmas > > > > > > > > This is last world build before the issue: > > > > http://logs.nslu2-linux.org/buildlogs/oe/world/warrior/log.report.20181219_112425.log > > > > ... > > > > == Tested changes (not included in master yet) - openembedded-core == > > > > latest upstream commit: > > > > 14c291e1fb gcc-runtime: Add missing libc dependency > > > > not included in master yet: > > > > 7e2ab991fa python/python3: use cc_basename to replace CC for checking > > > > compiler > > > > ced915026d python-native: fix one do_populate_sysroot warning > > > > aee47f3e82 netbase: add entry to /etc/hosts according to /etc/hostname > > > > a09e2db43a sstate: add support for caching shared workdir tasks > > > > c104a34166 grub2: Fix passing null to printf formats > > > > 6f364ff8c4 gnupg: Upgrade to 2.2.12 release > > > > 0224fec86b glibc: Upgrade towards 2.29 release > > > > 2486349782 gcc-9.0: Add recipes for upcoming gcc 9.0 release in mid-2019 > > > > b3ab29bdbb gcc-runtime: Drop building libmpx > > > > > > > > and this is the first which reported qemu-arm segfault: > > > > == Tested changes (not included in master yet) - openembedded-core == > > > > latest upstream commit: > > > > 95659bed3f populate_sdk_ext.bbclass: Include site.conf in parsing for > > > > contents for local.conf > > > > not included in master yet: > > > > 0c9db0ae7d python/python3: use cc_basename to replace CC for checking > > > > compiler > > > > bb3eb6bc41 python-native: fix one do_populate_sysroot warning > > > > 08a205f872 netbase: add entry to /etc/hosts according to /etc/hostname > > > > b81c8650d0 sstate: add support for caching shared workdir tasks > > > > 702be42dc9 glibc: Remove site_config and glibc-initial > > > > fc230822d8 gcc: Drop gcc-cross-initial and use gcc-cross instead > > > > 8652df3a0d gcc: Drop the -initial versions of the compiler > > > > 0c2f6dfa2f recipes: Drop virtual/libc-for-gcc > > > > c64531600d newlib: Move away from gcc-initial dependency > > > > 0d5fb4428f libssp: Remove dependency on gcc-initial > > > > 7dd8829d3e musl: Move away from gcc-initial dependency > > > > 9abdb4d6ca tcmode-default: Drop pinnings for gcc-initial based recipes > > > >
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, 28 Mar 2019 at 14:25, Tom Rini wrote: > Bumping PE is what this is for too, to not break package feeds after > we've done something wrong in PV. So lets bump PE and not break feeds. > Especially since this is so that CVE check starts to see and correctly > complain about issues that will result in "lets move this from master to > ..." and so break feeds. Bumping PE is a nuclear-armed hammer when setting CVE_VERSION="2.32" is sufficient and will go away when we upgrade to 2.32.1 onwards. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, 28 Mar 2019 at 14:08, Alexander Kanavin wrote: > The tag and version upstream are both 2.32. It's Khem who declared PV > to be 2.32.0 :) Yes I noticed that after sending. Let's ask Khem nicely to use the right version. :) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, Mar 28, 2019 at 03:08:00PM +0100, Alexander Kanavin wrote: > On Thu, 28 Mar 2019 at 14:51, Burton, Ross wrote: > > > Bumping PE is even worse as a PE never goes away. I say we leave it > > as it is, and ask upstream nicely if they'll match the tag/version in > > the future. > > The tag and version upstream are both 2.32. It's Khem who declared PV > to be 2.32.0 :) Bumping PE is what this is for too, to not break package feeds after we've done something wrong in PV. So lets bump PE and not break feeds. Especially since this is so that CVE check starts to see and correctly complain about issues that will result in "lets move this from master to ..." and so break feeds. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, 28 Mar 2019 at 14:51, Burton, Ross wrote: > Bumping PE is even worse as a PE never goes away. I say we leave it > as it is, and ask upstream nicely if they'll match the tag/version in > the future. The tag and version upstream are both 2.32. It's Khem who declared PV to be 2.32.0 :) Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] llvm: fix more places where '8.0' version of llvm was hardcoded
So that it says '8.0.0' to reflect the recent PV change.
Signed-off-by: Alexander Kanavin
---
meta/classes/meson.bbclass | 2 +-
...2-llvm-allow-env-override-of-exe-path.patch | 18 +-
meta/recipes-graphics/mesa/mesa.inc| 2 +-
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index aaf873cad2d..115d1aedcb1 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -89,7 +89,7 @@ ld = ${@meson_array('LD', d)}
strip = ${@meson_array('STRIP', d)}
readelf = ${@meson_array('READELF', d)}
pkgconfig = 'pkg-config'
-llvm-config = 'llvm-config8.0'
+llvm-config = 'llvm-config8.0.0'
[properties]
needs_exe_wrapper = true
diff --git
a/meta/recipes-devtools/llvm/llvm/0002-llvm-allow-env-override-of-exe-path.patch
b/meta/recipes-devtools/llvm/llvm/0002-llvm-allow-env-override-of-exe-path.patch
index 2970b0827bd..1369bcf78c7 100644
---
a/meta/recipes-devtools/llvm/llvm/0002-llvm-allow-env-override-of-exe-path.patch
+++
b/meta/recipes-devtools/llvm/llvm/0002-llvm-allow-env-override-of-exe-path.patch
@@ -51,7 +51,7 @@ index bec89fef98c..91b4d6e4c43 100644
ActiveObjRoot = LLVM_OBJ_ROOT;
} else if (sys::fs::equivalent(CurrentExecPrefix,
- Twine(LLVM_OBJ_ROOT) + "/bin")) {
-+ Twine(LLVM_OBJ_ROOT) + "/bin/llvm8.0")) {
++ Twine(LLVM_OBJ_ROOT) + "/bin/llvm8.0.0")) {
IsInDevelopmentTree = true;
DevelopmentTreeLayout = CMakeBuildModeStyle;
ActiveObjRoot = LLVM_OBJ_ROOT;
@@ -63,12 +63,12 @@ index bec89fef98c..91b4d6e4c43 100644
+ // llvm-config from within a target sysroot.
+ std::string Multilibdir = std::getenv("YOCTO_ALTERNATE_MULTILIB_NAME");
+ if (Multilibdir.empty()) {
-+Multilibdir = "/lib/llvm8.0" LLVM_LIBDIR_SUFFIX;
++Multilibdir = "/lib/llvm8.0.0" LLVM_LIBDIR_SUFFIX;
+ }
+
if (IsInDevelopmentTree) {
-ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include";
-+ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include/llvm8.0";
++ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include/llvm8.0.0";
ActivePrefix = CurrentExecPrefix;
// CMake organizes the products differently than a normal prefix style
@@ -78,17 +78,17 @@ index bec89fef98c..91b4d6e4c43 100644
case CMakeStyle:
- ActiveBinDir = ActiveObjRoot + "/bin";
- ActiveLibDir = ActiveObjRoot + "/lib" + LLVM_LIBDIR_SUFFIX;
-+ ActiveBinDir = ActiveObjRoot + "/bin/llvm8.0";
-+ ActiveLibDir = ActiveObjRoot + "/lib/llvm8.0" + LLVM_LIBDIR_SUFFIX;
++ ActiveBinDir = ActiveObjRoot + "/bin/llvm8.0.0";
++ ActiveLibDir = ActiveObjRoot + "/lib/llvm8.0.0" + LLVM_LIBDIR_SUFFIX;
ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
break;
case CMakeBuildModeStyle:
ActivePrefix = ActiveObjRoot;
- ActiveBinDir = ActiveObjRoot + "/bin/" + build_mode;
-+ ActiveBinDir = ActiveObjRoot + "/bin/llvm8.0/" + build_mode;
++ ActiveBinDir = ActiveObjRoot + "/bin/llvm8.0.0/" + build_mode;
ActiveLibDir =
- ActiveObjRoot + "/lib" + LLVM_LIBDIR_SUFFIX + "/" + build_mode;
-+ ActiveObjRoot + "/lib/llvm8.0" + LLVM_LIBDIR_SUFFIX + "/" +
build_mode;
++ ActiveObjRoot + "/lib/llvm8.0.0" + LLVM_LIBDIR_SUFFIX + "/" +
build_mode;
ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
break;
}
@@ -96,11 +96,11 @@ index bec89fef98c..91b4d6e4c43 100644
// We need to include files from both the source and object trees.
ActiveIncludeOption =
-("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot + "/include");
-+("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot +
"/include/llvm8.0");
++("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot +
"/include/llvm8.0.0");
} else {
ActivePrefix = CurrentExecPrefix;
-ActiveIncludeDir = ActivePrefix + "/include";
-+ActiveIncludeDir = ActivePrefix + "/include/llvm8.0";
++ActiveIncludeDir = ActivePrefix + "/include/llvm8.0.0";
SmallString<256> path(StringRef(LLVM_TOOLS_INSTALL_DIR));
sys::fs::make_absolute(ActivePrefix, path);
ActiveBinDir = path.str();
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 54818d7e0d2..ece74974b51 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -106,7 +106,7 @@ GALLIUMDRIVERS_append = ",virgl"
# keep --with-gallium-drivers separate, because when only one of gallium
versions is enabled, other 2 were adding --without-gallium-drivers
PACKAGECONFIG[gallium] = "--with-gallium-drivers=${GALLIUMDRIVERS},
--without-gallium-drivers"
-MESA_LLVM_RELEASE ?= "8.0"
+MESA_LLVM_RELEASE ?= "8.0.0"
PACKAGECONFIG[gallium-llvm] = "--enable-llvm --enable-llvm-shared-libs,
--disable-llvm, llvm${MESA_LLVM_RELEASE} llvm-native \
Re: [OE-core] [PATCH] wic/bootimg-efi.py: add new source parameter "initrd_rename"
On Wed, Mar 27, 2019 at 06:37:42PM +0800, Yongxin Liu wrote: > When using initrd in bootloader configuration file, we may want > the name of initrd to be fixed. However, the actual name of initrd > may change and depend on distro/machine's name. "initrd_rename" > gives user a chance to rename initrd in final wic image. > > Signed-off-by: Yongxin Liu I'm not nak'ing this patch, but I've long fixed this by just not using the "efi" plugin to make an EFI system and instead IMAGE_BOOT_FILES to say what goes where. There's a lot of cases bootimg-efi doesn't cover but are handled easily with IMAGE_BOOT_FILES. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, 28 Mar 2019 at 13:47, Tom Rini wrote: > > > I just had a look at the code in bitbake and yes, it actually even > > > tests that 1 < 1.0. I'd say that there's an argument for handling .0 > > > releases specially and considering 2.32 == 2.32.0. > > > > Of course that test exists for people using feeds, and at least dpkg > > thinks 2.32 < 2.32.0, so even if we changed the test the feed would > > still be broken. > > Breaking feeds on purpose is bad, so this is a case to pump PE? Bumping PE is even worse as a PE never goes away. I say we leave it as it is, and ask upstream nicely if they'll match the tag/version in the future. The CVE problem can be resolved by setting CVE_VERSION. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, Mar 28, 2019 at 01:17:11PM +, Burton, Ross wrote: > On Thu, 28 Mar 2019 at 13:15, Burton, Ross wrote: > > On Thu, 28 Mar 2019 at 12:07, Alexander Kanavin > > wrote: > > > The problem with setting PV properly, is that 2.32 is less than 2.32.0 > > > and will cause the 'version going backwards' problem. But if RP/Khem > > > are fine with it, I would prefer your patch. > > > > I just had a look at the code in bitbake and yes, it actually even > > tests that 1 < 1.0. I'd say that there's an argument for handling .0 > > releases specially and considering 2.32 == 2.32.0. > > Of course that test exists for people using feeds, and at least dpkg > thinks 2.32 < 2.32.0, so even if we changed the test the feed would > still be broken. Breaking feeds on purpose is bad, so this is a case to pump PE? -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib: set glib-specific cross properties
On Thu, Mar 28, 2019 at 5:48 AM Burton, Ross wrote:
> On Tue, 26 Mar 2019 at 19:41, Andre McCurdy wrote:
> > > > +growing_stack = false
> > >
> > > this is mostly true for arches we support but maybe a comment
> > > to check it when doing explicit arch ports ( e.g. arm can grown both
> ways)
> >
> > Not on EABI or any other ARM ABI which could possibly be targeted by
> > OE... unless you have evidence to prove otherwise?
>
> Evidence, no. Anecdotally:
>
> $ grep glib_cv_stack_grows *
> arc-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> arm-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> arm-darwin:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> arm-darwin8:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> ix86-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> microblaze-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mips64el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mips64el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mips64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mips64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsel-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsel-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa32r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa32r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa32r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa32r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa64r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa64r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa64r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mipsisa64r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mips-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> mips-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> nios2-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> powerpc-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> riscv32-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> riscv64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> sh-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> sparc-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
> x86_64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
>
> Yes, this technique needs to be extended and generalised so it can be
> overridden on a per-platform basis, but for now it appears that
> everything we care about has the same values.
All I asked was to add a comment about it
So if someone is porting OE to new architecture then this will be a great
hint to check for
>
> Ross
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] packagegroup-core-base-utils: remove lzip
lzip is pretty niche: people are typically either sticking with that they know
(gzip, bzip) or using xz. Data point: only one recipe in oe-core is shipped as
a .lz file.
Signed-off-by: Ross Burton
---
meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb | 1 -
1 file changed, 1 deletion(-)
diff --git
a/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
b/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
index 431dbb09261..611e0cafcc1 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
@@ -38,7 +38,6 @@ RDEPENDS_${PN} = "\
${@bb.utils.contains("MACHINE_FEATURES", "keyboard", "kbd", "", d)} \
kmod \
less \
-lzip \
ncurses-tools \
net-tools \
parted \
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] at-spi2-core:upgrade 2.30.0 -> 2.32.0
Documentation got disabled:
packages/corei7-64-poky-linux/at-spi2-core/at-spi2-core-doc: FILELIST:
removed all items
"/usr/share/gtk-doc/html/libatspi/right-insensitive.png
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-table-cell.html
/usr/share/gtk-doc/html/libatspi/AtspiMatchRule.html
/usr/share/gtk-doc/html/libatspi/api-index-full.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-image.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-misc.html
/usr/share/gtk-doc/html/libatspi/AtspiAccessible.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-constants.html
/usr/share/gtk-doc/html/libatspi/AtspiRelation.html
/usr/share/gtk-doc/html/libatspi/AtspiDeviceListener.html
/usr/share/gtk-doc/html/libatspi/index.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-value.html
/usr/share/gtk-doc/html/libatspi/AtspiObject.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-registry.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-selection.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-table.html
/usr/share/gtk-doc/html/libatspi/left-insensitive.png
/usr/share/gtk-doc/html/libatspi/annotation-glossary.html
/usr/share/gtk-doc/html/libatspi/up.png
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-listener-private.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-types.html
/usr/share/gtk-doc/html/libatspi/right.png
/usr/share/gtk-doc/html/libatspi/style.css
/usr/share/gtk-doc/html/libatspi/up-insensitive.png
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-misc-private.html
/usr/share/gtk-doc/html/libatspi/AtspiStateSet.html
/usr/share/gtk-doc/html/libatspi/ch01.html
/usr/share/gtk-doc/html/libatspi/AtspiHyperlink.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-action.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-collection.html
/usr/share/gtk-doc/html/libatspi/left.png
/usr/share/gtk-doc/html/libatspi/libatspi.devhelp2
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-editabletext.html
/usr/share/gtk-doc/html/libatspi/object-tree.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-document.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-component.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-text.html
/usr/share/gtk-doc/html/libatspi/libatspi-AtspiApplication.html
/usr/share/gtk-doc/html/libatspi/libatspi-atspi-hypertext.html
/usr/share/gtk-doc/html/libatspi/home.png
/usr/share/gtk-doc/html/libatspi/AtspiEventListener.html"
Ross
On Wed, 27 Mar 2019 at 08:19, Zang Ruochen wrote:
>
> upgrade from at-spi2-core_2.30.0.bb to at-spi2-core_2.32.0.bb
>
> Signed-off-by: Zang Ruochen
> ---
> .../atk/{at-spi2-core_2.30.0.bb => at-spi2-core_2.32.0.bb}| 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-support/atk/{at-spi2-core_2.30.0.bb =>
> at-spi2-core_2.32.0.bb} (92%)
>
> diff --git a/meta/recipes-support/atk/at-spi2-core_2.30.0.bb
> b/meta/recipes-support/atk/at-spi2-core_2.32.0.bb
> similarity index 92%
> rename from meta/recipes-support/atk/at-spi2-core_2.30.0.bb
> rename to meta/recipes-support/atk/at-spi2-core_2.32.0.bb
> index d0b567a5e5..0eaa7b55c5 100644
> --- a/meta/recipes-support/atk/at-spi2-core_2.30.0.bb
> +++ b/meta/recipes-support/atk/at-spi2-core_2.32.0.bb
> @@ -8,8 +8,8 @@ MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
> SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
> "
>
> -SRC_URI[md5sum] = "d4f22c66b3210ffe6b10d01c04e008b5"
> -SRC_URI[sha256sum] =
> "0175f5393d19da51f4c11462cba4ba6ef3fa042abf1611a70bdfed586b7bfb2b"
> +SRC_URI[md5sum] = "57269004541646c4c5cf0bcb7c99bb5b"
> +SRC_URI[sha256sum] =
> "43a435d213f8d4b55e8ac83a46ae976948dc511bb4a515b69637cb36cf0e7220"
>
> X11DEPENDS = "virtual/libx11 libxi libxtst"
>
> --
> 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] [PATCH 1/3] atk:upgrade 2.30.0 -> 2.32.0
Please remember to read the warnings:
WARNING: atk-2.32.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify
devtool finish --force-patch-refresh
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0001-meson.build-enable-introspection-for-cross-compile.patch
patching file atk/meson.build
Hunk #1 succeeded at 137 with fuzz 1.
Now at patch 0001-meson.build-enable-introspection-for-cross-compile.patch
Ross
On Wed, 27 Mar 2019 at 08:19, Zang Ruochen wrote:
>
> upgrade from atk_2.30.0.bb to atk_2.32.0.bb
> delete atk/0001-Switch-from-filename-to-basename.patch beacuse of this
> patch has been fixed
>
> Signed-off-by: Zang Ruochen
> ---
> ...001-Switch-from-filename-to-basename.patch | 38 ---
> .../atk/{atk_2.30.0.bb => atk_2.32.0.bb} | 5 +--
> 2 files changed, 2 insertions(+), 41 deletions(-)
> delete mode 100644
> meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
> rename meta/recipes-support/atk/{atk_2.30.0.bb => atk_2.32.0.bb} (86%)
>
> diff --git
> a/meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
> b/meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
> deleted file mode 100644
> index 047e81fb61..00
> --- a/meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -Upstream-Status: Submitted
> -
> -From 0330251715fee908f2f162565d4fa1df5030d0c0 Mon Sep 17 00:00:00 2001
> -From: Jeremy Puhlman
> -Date: Thu, 14 Jun 2018 17:21:49 +
> -Subject: [PATCH] Switch from filename to basename
> -
> -When atk-enum-types.h is installed in to a system, the user likely has
> -no access to the location where the headers were built, especially if
> -the software was built in a sysroot environment. If the headers were
> -built for a mulitlib environment, the build pathing may be different.
> -Subsequently, if two mulitlib variants of atk are installed together the
> -headers conflict for no other reason then they were built in two
> -different locations. Switching from filename to basename, still should
> -provide sufficient information on the providence of the enums, while not
> -conflicting for really no good reason.
> -
> -Signed-off-by: Jeremy Puhlman
>
> - atk/atk-enum-types.h.template | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/atk/atk-enum-types.h.template b/atk/atk-enum-types.h.template
> -index 7b4cec4..8321c24 100644
> a/atk/atk-enum-types.h.template
> -+++ b/atk/atk-enum-types.h.template
> -@@ -14,7 +14,7 @@ G_BEGIN_DECLS
> -
> - /*** BEGIN file-production ***/
> -
> --/* enumerations from "@filename@" */
> -+/* enumerations from "@basename@" */
> - /*** END file-production ***/
> -
> - /*** BEGIN value-header ***/
> ---
> -2.14.1.459.g238e487
> -
> diff --git a/meta/recipes-support/atk/atk_2.30.0.bb
> b/meta/recipes-support/atk/atk_2.32.0.bb
> similarity index 86%
> rename from meta/recipes-support/atk/atk_2.30.0.bb
> rename to meta/recipes-support/atk/atk_2.32.0.bb
> index 4e2dacbc4d..5425c8e57e 100644
> --- a/meta/recipes-support/atk/atk_2.30.0.bb
> +++ b/meta/recipes-support/atk/atk_2.32.0.bb
> @@ -30,10 +30,9 @@ EXTRA_OEMESON_append_class-target = "
> ${@bb.utils.contains('GTKDOC_ENABLED', 'Tr
>
> SRC_URI_append = " \
>
> file://0001-meson.build-enable-introspection-for-cross-compile.patch \
> - file://0001-Switch-from-filename-to-basename.patch \
> "
> -SRC_URI[archive.md5sum] = "769c85005d392ad17ffbc063f2d26454"
> -SRC_URI[archive.sha256sum] =
> "dd4d90d4217f2a0c1fee708a96c2c19d26fef0952e1ead1938ab632c027b"
> +SRC_URI[archive.md5sum] = "c10b0b2af3c199e42caa6275b845c49d"
> +SRC_URI[archive.sha256sum] =
> "cb41feda7fe4ef0daa024471438ea0219592baf7c291347e5a858bb64e4091cc"
>
> BBCLASSEXTEND = "native nativesdk"
>
> --
> 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] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, 28 Mar 2019 at 13:15, Burton, Ross wrote: > On Thu, 28 Mar 2019 at 12:07, Alexander Kanavin > wrote: > > The problem with setting PV properly, is that 2.32 is less than 2.32.0 > > and will cause the 'version going backwards' problem. But if RP/Khem > > are fine with it, I would prefer your patch. > > I just had a look at the code in bitbake and yes, it actually even > tests that 1 < 1.0. I'd say that there's an argument for handling .0 > releases specially and considering 2.32 == 2.32.0. Of course that test exists for people using feeds, and at least dpkg thinks 2.32 < 2.32.0, so even if we changed the test the feed would still be broken. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, 28 Mar 2019 at 12:07, Alexander Kanavin wrote: > The problem with setting PV properly, is that 2.32 is less than 2.32.0 > and will cause the 'version going backwards' problem. But if RP/Khem > are fine with it, I would prefer your patch. I just had a look at the code in bitbake and yes, it actually even tests that 1 < 1.0. I'd say that there's an argument for handling .0 releases specially and considering 2.32 == 2.32.0. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib: set glib-specific cross properties
On Tue, 26 Mar 2019 at 19:41, Andre McCurdy wrote:
> > > +growing_stack = false
> >
> > this is mostly true for arches we support but maybe a comment
> > to check it when doing explicit arch ports ( e.g. arm can grown both ways)
>
> Not on EABI or any other ARM ABI which could possibly be targeted by
> OE... unless you have evidence to prove otherwise?
Evidence, no. Anecdotally:
$ grep glib_cv_stack_grows *
arc-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
arm-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
arm-darwin:glib_cv_stack_grows=${glib_cv_stack_grows=no}
arm-darwin8:glib_cv_stack_grows=${glib_cv_stack_grows=no}
ix86-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
microblaze-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mips64el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mips64el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mips64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mips64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsel-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsel-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa32r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa32r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa32r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa32r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa64r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa64r6el-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa64r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mipsisa64r6-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mips-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
mips-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
nios2-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
powerpc-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
riscv32-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
riscv64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
sh-common:glib_cv_stack_grows=${glib_cv_stack_grows=no}
sparc-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
x86_64-linux:glib_cv_stack_grows=${glib_cv_stack_grows=no}
Yes, this technique needs to be extended and generalised so it can be
overridden on a per-platform basis, but for now it appears that
everything we care about has the same values.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] llvm: support older toolchains
LLVM is now warning if your host compiler is gcc <5.1, and some of our supported
operating systems still only have 4.8.5. Set
LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN so those builds continue to work, hopefully
we retire the old operating systems before LLVM requires 5.1+.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/llvm/llvm_git.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/llvm/llvm_git.bb
b/meta/recipes-devtools/llvm/llvm_git.bb
index 01a7da8ebdc..7832441482e 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -70,6 +70,7 @@ EXTRA_OECMAKE += "-DLLVM_ENABLE_ASSERTIONS=OFF \
-DFFI_INCLUDE_DIR=$(pkg-config --variable=includedir libffi)
\
-DLLVM_OPTIMIZED_TABLEGEN=ON \
-DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS}' \
+ -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON \
-DPYTHON_EXECUTABLE=${HOSTTOOLS_DIR}/python2 \
-G Ninja"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] binutils: fix upstream version check
On Thu, 28 Mar 2019 at 13:06, ChenQi wrote: > I just sent out a patch to change the PV to "2.32". > If it's 2.32, does this var still needs to be set? No, it does not need to be set then, but changing PV to 2.32 is otherwise problematic - see my other email I just sent. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] binutils: fix upstream version check
Hi Alexander,
I just sent out a patch to change the PV to "2.32".
If it's 2.32, does this var still needs to be set?
Best Regards,
Chen Qi
On 03/27/2019 10:09 PM, Alexander Kanavin wrote:
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/binutils/binutils-2.32.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 74239868151..15406441241 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -14,6 +14,11 @@ def binutils_branch_version(d):
pvsplit = d.getVar('PV').split('.')
return pvsplit[0] + "_" + pvsplit[1]
+# Actual upstream version is 2.32 (without the .0), so we have to set
+# UPSTREAM_VERSION_UNKNOWN to avoid the version check failure. The line can
+# be removed when a new version of binutils is released (if the PV is then
+# correctly set to match the upstream version tag).
+UPSTREAM_VERSION_UNKNOWN = "1"
PV = "2.32.0"
BINUPV = "${@binutils_branch_version(d)}"
#BRANCH = "binutils-${BINUPV}-branch"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
On Thu, 28 Mar 2019 at 13:03, Chen Qi wrote: > Setting PV to "2.32.0" results in cve checking tools failing to > report the actual unfixed CVEs. We need to change it to "2.32". > After the change, when `bitbake -c cve_check binutils-native', we have: I sent a related patch yesterday: http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280511.html The problem with setting PV properly, is that 2.32 is less than 2.32.0 and will cause the 'version going backwards' problem. But if RP/Khem are fine with it, I would prefer your patch. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] binutils: fix PV to respect upstream tag and also cve database
Setting PV to "2.32.0" results in cve checking tools failing to
report the actual unfixed CVEs. We need to change it to "2.32".
After the change, when `bitbake -c cve_check binutils-native', we have:
binutils-native-2.32-r0 do_cve_check: Found unpatched CVE (CVE-2018-1000876
CVE-2019-9070 CVE-2019-9071 CVE-2019-9072 CVE-2019-9073 CVE-2019-9074
CVE-2019-9075 CVE-2019-9076 CVE-2019-9077)
Checking the upstream repo, it has tags like:
binutils-2_29
binutils-2_29_1
binutils-2_29_1.1
binutils-2_30
binutils-2_31
binutils-2_31_1
binutils-2_32
So we'd better respect both upstream tags and cve database and use '2.32'.
If binutils 2.32.1 is released some day, we then change the PV to '2.32.1'.
Signed-off-by: Chen Qi
---
meta/recipes-devtools/binutils/binutils-2.32.inc | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 7423986..b728c4e 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -10,13 +10,7 @@ LIC_FILES_CHKSUM="\
file://bfd/COPYING;md5=d32239bcb673463ab874e80d47fae504\
"
-def binutils_branch_version(d):
-pvsplit = d.getVar('PV').split('.')
-return pvsplit[0] + "_" + pvsplit[1]
-
-PV = "2.32.0"
-BINUPV = "${@binutils_branch_version(d)}"
-#BRANCH = "binutils-${BINUPV}-branch"
+PV = "2.32"
BRANCH ?= "binutils-2_32-branch"
UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] binutils: fix PV to respect upstream tag and also cve database
*** BLURB HERE *** The following changes since commit 35742c10f531ba451c06a4e360fecfb55f358b35: ref-manual: Removed DISK_DESCRIPTION variable from glossary (2019-03-26 15:38:56 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/binutils-pv http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/binutils-pv Chen Qi (1): binutils: fix PV to respect upstream tag and also cve database meta/recipes-devtools/binutils/binutils-2.32.inc | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] networkmanager: upgrade 1.14.4 -> 1.14.6
On Thu, Mar 28, 2019 at 12:14 PM Arturo Buzarra wrote: > > * License checksum changed > * Patch was aligned but have no resources to test them > > Signed-off-by: Arturo Buzarra * This should go to meta-oe mailing list * meta-oe updated to 1.16.0 already Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] networkmanager: upgrade 1.14.4 -> 1.14.6
* License checksum changed
* Patch was aligned but have no resources to test them
Signed-off-by: Arturo Buzarra
---
...ttings-settings-property-documentati.patch | 33 +++
...ger_1.14.4.bb => networkmanager_1.14.6.bb} | 6 ++--
2 files changed, 15 insertions(+), 24 deletions(-)
rename
meta-networking/recipes-connectivity/networkmanager/{networkmanager_1.14.4.bb
=> networkmanager_1.14.6.bb} (95%)
diff --git
a/meta-networking/recipes-connectivity/networkmanager/networkmanager/0003-Do-not-create-settings-settings-property-documentati.patch
b/meta-networking/recipes-connectivity/networkmanager/networkmanager/0003-Do-not-create-settings-settings-property-documentati.patch
index c50293c09..7d9bc32ad 100644
---
a/meta-networking/recipes-connectivity/networkmanager/networkmanager/0003-Do-not-create-settings-settings-property-documentati.patch
+++
b/meta-networking/recipes-connectivity/networkmanager/networkmanager/0003-Do-not-create-settings-settings-property-documentati.patch
@@ -13,43 +13,34 @@ Upstream-Status: Inappropriate [OE specific]
Signed-off-by: Andreas Müller
---
- Makefile.am | 20
+ Makefile.am | 11 ---
configure.ac | 5 -
- 2 files changed, 25 deletions(-)
+ 2 files changed, 16 deletions(-)
diff --git a/Makefile.am b/Makefile.am
-index 1e100f6..d31e3c1 100644
+index e1b442e99..d977e9457 100644
--- a/Makefile.am
+++ b/Makefile.am
-@@ -1115,9 +1115,7 @@ EXTRA_DIST += \
+@@ -1117,9 +1117,7 @@ EXTRA_DIST += \
if HAVE_INTROSPECTION
-
+
libnm_noinst_data = \
- libnm/nm-property-docs.xml \
libnm/nm-settings-docs-overrides.xml \
- libnm/nm-settings-docs.xml \
libnm/nm-settings-keyfile-docs.xml \
libnm/nm-settings-ifcfg-rh-docs.xml
-
-@@ -3692,27 +3690,9 @@ $(clients_common_libnmc_base_la_OBJECTS):
$(libnm_lib_h_pub_mkenums)
+
+@@ -3696,18 +3694,9 @@ $(clients_common_libnmc_base_la_OBJECTS):
$(libnm_lib_h_pub_mkenums)
$(clients_common_libnmc_base_la_OBJECTS): clients/common/.dirstamp
-
+
clients_common_settings_doc_h = clients/common/settings-docs.h
-if HAVE_INTROSPECTION
-$(clients_common_settings_doc_h): clients/common/settings-docs.xsl
libnm/nm-property-docs.xml clients/common/.dirstamp
- $(AM_V_GEN) $(XSLTPROC) --output $@ $< $(word 2,$^)
-DISTCLEANFILES += $(clients_common_settings_doc_h)
-check-local-settings-docs: $(clients_common_settings_doc_h)
-- @if test -z "$$NMTST_NO_CHECK_SETTINGS_DOCS" ; then \
-- if ! cmp -s "$(srcdir)/$(clients_common_settings_doc_h).in"
"$(builddir)/$(clients_common_settings_doc_h)" ; then \
-- if test "$$NM_TEST_REGENERATE" == 1 ; then \
-- cp -f
"$(builddir)/$(clients_common_settings_doc_h)"
"$(srcdir)/$(clients_common_settings_doc_h).in"; \
-- else \
-- echo "The generated file
\"$(builddir)/$(clients_common_settings_doc_h)\" differs from the source file
\"$(srcdir)/$(clients_common_settings_doc_h).in\". You probably should copy the
generated file over to the source file. You can skip this test by setting
\$$NMTST_NO_CHECK_SETTINGS_DOCS=yes". You can also automatically copy the file
by rerunning the test with \$$NM_TEST_REGENERATE=1 ; \
-- false; \
-- fi; \
-- fi;\
-- fi
+- $(srcdir)/tools/check-settings-docs.sh "$(srcdir)" "$(builddir)"
"$(clients_common_settings_doc_h)"
-check_local += check-local-settings-docs
-else
$(clients_common_settings_doc_h): $(clients_common_settings_doc_h).in
clients/common/.dirstamp
@@ -60,7 +51,7 @@ index 1e100f6..d31e3c1 100644
$(clients_common_settings_doc_h) \
$(clients_common_settings_doc_h).in
diff --git a/configure.ac b/configure.ac
-index 79dc3b9..23d14a6 100644
+index 1f9dcb3c7..ca8db970a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1195,11 +1195,6 @@ GTK_DOC_CHECK(1.0)
@@ -75,6 +66,6 @@ index 79dc3b9..23d14a6 100644
AC_PATH_PROG(PERL, perl)
if test -z "$PERL"; then
AC_MSG_ERROR([--enable-introspection requires perl])
---
-2.14.5
+--
+2.21.0
diff --git
a/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
b/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.6.bb
similarity index 95%
rename from
meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
rename to
meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.6.bb
index f21600eda..c10403ba1 100644
---
a/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
+++
b/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.6.bb
@@ -5,7 +5,7 @@ SECTION = "net/misc"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=cbbffd568227ada506640fe950a4823b \
file://libnm-util/COPYING;md5=1c4fa765d6eb3cd2fbd84344a1b816cd \
-
[OE-core] [PATCH] glibc: always use bfd linker
* Work around broken ld-2.29.so when gold is used
causing qemu-arm to segfault during e.g. gobject-introspection
or postinst at do_rootfs time, more details in:
http://lists.openembedded.org/pipermail/openembedded-devel/2019-March/198937.html
https://sourceware.org/bugzilla/show_bug.cgi?id=24148
https://sourceware.org/bugzilla/show_bug.cgi?id=10937
https://sourceware.org/bugzilla/show_bug.cgi?id=18103
Signed-off-by: Martin Jansa
---
meta/recipes-core/glibc/glibc_2.29.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/glibc/glibc_2.29.bb
b/meta/recipes-core/glibc/glibc_2.29.bb
index 9184c5932c..073d1533e3 100644
--- a/meta/recipes-core/glibc/glibc_2.29.bb
+++ b/meta/recipes-core/glibc/glibc_2.29.bb
@@ -110,7 +110,7 @@ do_configure () {
do_compile () {
# -Wl,-rpath-link /lib in LDFLAGS can cause breakage if
another glibc is in staging
- unset LDFLAGS
+ LDFLAGS="-fuse-ld=bfd"
base_do_compile
echo "Adjust ldd script"
if [ -n "${RTLDLIST}" ]
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] Systemd: Add pattern matching support to PACKAGECONFIG
libpcre2 is needed to enable grep option to journalctl.
Signed-off-by: Vincent Prince
---
Changes in v3:
- Reformat commit message
Changes in v2:
- Fix false case option
meta/recipes-core/systemd/systemd_241.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/systemd/systemd_241.bb
b/meta/recipes-core/systemd/systemd_241.bb
index a12b9ab..bfbfc81 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -151,6 +151,7 @@ PACKAGECONFIG[nss-mymachines] =
"-Dnss-mymachines=true,-Dnss-mymachines=false"
PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
+PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=false,libpcre2"
PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
PACKAGECONFIG[portabled] = "-Dportabled=true,-Dportabled=false"
PACKAGECONFIG[qrencode] = "-Dqrencode=true,-Dqrencode=false,qrencode"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] package_ipk: handle exception for subprocess command
When opkg-build command fails to execute, subprocess is returned with
exception instead of printing to stderr. This causes the error logging
not to be printed out, as the "finally" statement does not contain any
bitbake error output.
One example of this behavior is when the package name contains uppercase
character, which are rejected by opkg-build, subprocess.check_output
would except and no error log would be produced.
This commit catches the exception subprocess.CalledProcessError and
produces bb.error output visible to the user.
Signed-off-by: Andrey Zhizhikin
---
meta/classes/package_ipk.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index d1b317b42b..f181f5b4fd 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -234,6 +234,8 @@ def ipk_write_pkg(pkg, d):
ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir, pkgname, ipkver,
d.getVar('PACKAGE_ARCH'))
sign_ipk(d, ipk_to_sign)
+except subprocess.CalledProcessError as exc:
+bb.error("OPKG Build failed: %s" % exc.output)
finally:
cleanupcontrol(root)
bb.utils.unlockfile(lf)
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] gdk-pixbuf: update to 2.38.0
On 3/28/19 10:32 AM, Changqing Li wrote:
Hi, Alexander
I met a problem after gdk-pixbuf upgrade to 2.38.0. Seems you have do
some work about this package,
could you help to take a look if you have any idea about this problem
? Thanks in advance.
bitbake core-image-minimal with below local.conf
MACHINE ?= "qemux86"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
KERNEL_FEATURES_append = " cfg/systemd.scc"
DISTRO_FEATURES_append = " polkit"
IMAGE_INSTALL_append = " packagegroup-xfce-base"
Error:
ERROR: core-image-minimal-1.0-r0 do_rootfs: [log_check]
core-image-minimal: found 1 error message in the logfile:
[log_check] ** (process:162531): CRITICAL **: 02:10:12.174: Failed to
get connection to xfconfd: Cannot autolaunch D-Bus without X11 $DISPLAY
ERROR: core-image-minimal-1.0-r0 do_rootfs:
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/buildarea3/cli10/yocto/builds/systemd/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.15350
Some other info:
1. problem only reproduce after add "IMAGE_INSTALL_append = "
packagegroup-xfce-base""
2. error was reproduces during run update-pixbuf-cache during
do_rootrfs, but cannot reproduce if manually run in devshell enviroment
3. version 2.36.11 don't have this problem. from 2.36.12, this
problem appeared.
4. 2.36.11 default open x11 packageconfig, but 2.38.0 disable it, I
tried with add x11 into packageconfig, but not resolve this problem.
I have found the code snip which cause this problem. And I will send
the fix later. problem caused by call of function g_file_new_for_path.
but I don't quite understand why since not familiar with this part. I
will also send upstream for review.
On 2/22/19 10:16 PM, Alexander Kanavin wrote:
Drop 0001-Disable-tests-in-native-builds.patch as upstream has fixed the issue.
Rework 0001-Fix-a-couple-of-decisions-around-cross-compilation.patch to
enable generation of loaders.cache in target builds (using a native tool),
because otherwise building tests becomes impossible.
Rework 0002-Work-around-thumbnailer-cross-compile-failure.patch into
0003-target-only-Work-around-thumbnailer-cross-compile-fa.patch
(which deals with substituting native tools in cross builds) and
0004-Do-not-run-tests-when-building.patch (which avoids running
test binaries during cross builds).
Rebase fatal-loader.patch.
License checksum updates as COPYING file had 2.0 version of LGPL and
has been replaced with 2.1 version.
Take meson's x11 and installed_tests options into use.
Install gdk-pixbuf-query-loaders also into $bindir, as we need the native
version during cross compile.
Signed-off-by: Alexander Kanavin
---
.../0001-Disable-tests-in-native-builds.patch | 31 -
...f-decisions-around-cross-compilation.patch | 38 +++--
...nd-thumbnailer-cross-compile-failure.patch | 131 --
...-around-thumbnailer-cross-compile-fa.patch | 96 +
.../0004-Do-not-run-tests-when-building.patch | 39 ++
.../gdk-pixbuf/gdk-pixbuf/fatal-loader.patch | 37 +++--
...pixbuf_2.36.11.bb => gdk-pixbuf_2.38.0.bb} | 44 +++---
7 files changed, 197 insertions(+), 219 deletions(-)
delete mode 100644
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Disable-tests-in-native-builds.patch
delete mode 100644
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0002-Work-around-thumbnailer-cross-compile-failure.patch
create mode 100644
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0003-target-only-Work-around-thumbnailer-cross-compile-fa.patch
create mode 100644
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0004-Do-not-run-tests-when-building.patch
rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf_2.36.11.bb =>
gdk-pixbuf_2.38.0.bb} (76%)
diff --git
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Disable-tests-in-native-builds.patch
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Disable-tests-in-native-builds.patch
deleted file mode 100644
index 1e45b716b93..000
---
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Disable-tests-in-native-builds.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From b287cb313dbfac3257f1ab451b19ba59580f78e1 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin
-Date: Mon, 18 Feb 2019 16:00:12 +0100
-Subject: [PATCH] Disable tests in native builds.
-
-They have found to be problematic at least on Centos 7:
-https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/296/steps/7/logs/step1b
-
-With autotools this was not a problem because it had a configuration
-switch for disabling test, which was used. Meson has no such facility :(
-
-Upstream-Status: Inappropriate [oe-core specific]
-Signed-off-by: Alexander Kanavin
-
- meson.build | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/meson.build b/meson.build
-index 92c4049..0871c84 100644
a/meson.build
-+++ b/meson.build
-@@
Re: [OE-core] [PATCH] resulttool/merge: Merge files from folders and control add testseries
Hi RP, Yes, we will separate the changes into different patches as suggested. Thank you for your inputs. Thanks, Ee Peng -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Thursday, March 28, 2019 3:43 PM To: Yeoh, Ee Peng ; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] resulttool/merge: Merge files from folders and control add testseries Hi Ee Peng, This patch isn't really in a form where it can be easily reviewed or accepted. A given patch needs to do one specific thing, so for example if you're renaming/refactoring a function that would belong in its own patch. If you're changing functionality, that would also be best in its own patch. In the patch below you make various refactoring changes as well as making functionality changes meaning its very hard to separate the real functionality change from the rest of the "noise" of the renaming and refactoring. This makes review extremely difficult. I'm not even sure I agree with some of the renaming/refactoring, e.g. make_directory_and_write_json_file is a horrible name for a function and it only appears to be called once? There are probably other issues but its really hard to tell. Could you split up this series, ideally showing the functionality change in its own patch please. I'm not promising it would all be accepted but it would at least allow review and allow the changes to be understood. Cheers, Richard On Thu, 2019-03-28 at 12:54 +0800, Yeoh Ee Peng wrote: > QA team execute extra testing that create multiple test result files, > where these test result files need to be merged under various use > cases. > Furthermore, during results merging, user need control over the > testseries configuration creation as this configuration has important > implication to report and regression. > > Current merge do not support merge results where both base and target > are directory. > > Traceback (most recent call last): > File "/home/poky/scripts/resulttool", line 93, in > sys.exit(main()) > File "/home/poky/scripts/resulttool", line 87, in main > ret = args.func(args, logger) > File "/home/poky/scripts/lib/resulttool/merge.py", line 22, in merge > resultutils.append_resultsdata(results, args.base_results, > configmap=resultutils.store_map) > File "/home/poky/scripts/lib/resulttool/resultutils.py", line 47, in > append_resultsdata > with open(f, "r") as filedata: > IsADirectoryError: [Errno 21] Is a directory: > '' > > This patches enable merge for both base and target as directory. > Also, enable control the creation of testseries configuration. > > Previously the append_resultsdata function only allow append the > results data to the map_results data (where map_results data wrapped > the results data with configuration map as the key). > Initially, we tried to implement an extra function where it will > enable append one map_results to another map_results data. But we > abandoned this alternative as this new append function will be pretty > much a duplicated function to the original append_resultsdata, and > these will create two append functions which they might be both hard > to maintain and confusing. Thus, we tried to refactor the append > function to enable a single append function to be used in all the > situation. Futhermore, since the map_results were only needed by > report and regression, we pulled the instructions used to turn results > data to map_results data to another function. > Finally, we renamed the functions and arguments to clearly seperated > the functions using results data from the one using map_results data. > > Signed-off-by: Yeoh Ee Peng > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] resulttool/merge: Merge files from folders and control add testseries
Hi Ee Peng, This patch isn't really in a form where it can be easily reviewed or accepted. A given patch needs to do one specific thing, so for example if you're renaming/refactoring a function that would belong in its own patch. If you're changing functionality, that would also be best in its own patch. In the patch below you make various refactoring changes as well as making functionality changes meaning its very hard to separate the real functionality change from the rest of the "noise" of the renaming and refactoring. This makes review extremely difficult. I'm not even sure I agree with some of the renaming/refactoring, e.g. make_directory_and_write_json_file is a horrible name for a function and it only appears to be called once? There are probably other issues but its really hard to tell. Could you split up this series, ideally showing the functionality change in its own patch please. I'm not promising it would all be accepted but it would at least allow review and allow the changes to be understood. Cheers, Richard On Thu, 2019-03-28 at 12:54 +0800, Yeoh Ee Peng wrote: > QA team execute extra testing that create multiple test result files, > where these test result files need to be merged under various use > cases. > Furthermore, during results merging, user need control over the > testseries configuration creation as this configuration has important > implication to report and regression. > > Current merge do not support merge results where both base and target > are directory. > > Traceback (most recent call last): > File "/home/poky/scripts/resulttool", line 93, in > sys.exit(main()) > File "/home/poky/scripts/resulttool", line 87, in main > ret = args.func(args, logger) > File "/home/poky/scripts/lib/resulttool/merge.py", line 22, in > merge > resultutils.append_resultsdata(results, args.base_results, > configmap=resultutils.store_map) > File "/home/poky/scripts/lib/resulttool/resultutils.py", line 47, > in append_resultsdata > with open(f, "r") as filedata: > IsADirectoryError: [Errno 21] Is a directory: > '' > > This patches enable merge for both base and target as directory. > Also, enable control the creation of testseries configuration. > > Previously the append_resultsdata function only allow append > the results data to the map_results data (where map_results data > wrapped the results data with configuration map as the key). > Initially, we tried to implement an extra function where it will > enable append one map_results to another map_results data. But > we abandoned this alternative as this new append function will be > pretty much a duplicated function to the original append_resultsdata, > and these will create two append functions which they might be both > hard to maintain and confusing. Thus, we tried to refactor the > append function to enable a single append function to be used > in all the situation. Futhermore, since the map_results were > only needed by report and regression, we pulled the instructions > used to turn results data to map_results data to another function. > Finally, we renamed the functions and arguments to clearly > seperated the functions using results data from the one using > map_results data. > > Signed-off-by: Yeoh Ee Peng > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] less:upgrade 549 -> 550
-Upgrade from less_549.bb to less_550.bb
Signed-off-by: Zang Ruochen
---
meta/recipes-extended/less/{less_549.bb => less_550.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/less/{less_549.bb => less_550.bb} (89%)
diff --git a/meta/recipes-extended/less/less_549.bb
b/meta/recipes-extended/less/less_550.bb
similarity index 89%
rename from meta/recipes-extended/less/less_549.bb
rename to meta/recipes-extended/less/less_550.bb
index 140c89fcb0..bb1618f1eb 100644
--- a/meta/recipes-extended/less/less_549.bb
+++ b/meta/recipes-extended/less/less_550.bb
@@ -28,8 +28,8 @@ DEPENDS = "ncurses"
SRC_URI = "http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \
"
-SRC_URI[md5sum] = "d12863d348077739a4d3bc67ad9b7f00"
-SRC_URI[sha256sum] =
"eec42357903faabfb294ffcc41ff08cbb29db54db46568cd8d0ed15a0482e19d"
+SRC_URI[md5sum] = "8caff88e34afff512b663d7c690bd2cf"
+SRC_URI[sha256sum] =
"6a53639f08d7ed05b6e104b82c32193f79ac01a3eddb20e114e1c261948bd57b"
UPSTREAM_CHECK_URI = "http://www.greenwoodsoftware.com/less/download.html;
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
