[OE-core] [PATCH v2 2/3] ccmake.bbclass: Create a cml1 style class for the CMake curses UI

[Nathan Rossi]

The ccmake bbclass implements two tasks. The first task 'ccmake'
preserves the configured state of CMakeCache.txt (generated from the
configure task) and invokes the 'ccmake' program within a oe_terminal
execution. The user can then review, select and modify configuration
options and once satisfied with the configuration exit ccmake. Once
ccmake has exited the build can be run and the updated configuration
should be reflected in the output build.

The ccmake bbclass has a second task 'ccmake_diffconfig' to compute the
differences in configuration which was modified by ccmake. Since there
are many ways to persist the configuration changes within recipes and
layer configuration, the differences are emitted as a bitbake recipe
fragment (configuration.inc) using EXTRA_OECMAKE as well as a CMake
script file which can be used as a input to cmake via the '-C' argument.
Both files are generated in the WORKDIR of the build and the paths to
the files are written as output from the build. It is then up to the
user to take this configuration and apply it to the desired location.

Signed-off-by: Nathan Rossi 
---
Changes in v2:
- Fix up bb.fatal using format of undefined variable 'e'
- Fix up indentation of else case "No configuration differences" message
---
 meta/classes/ccmake.bbclass | 97 +
 1 file changed, 97 insertions(+)
 create mode 100644 meta/classes/ccmake.bbclass

diff --git a/meta/classes/ccmake.bbclass b/meta/classes/ccmake.bbclass
new file mode 100644
index 00..4114daa61b
--- /dev/null
+++ b/meta/classes/ccmake.bbclass
@@ -0,0 +1,97 @@
+inherit terminal
+
+python do_ccmake() {
+import shutil
+
+# copy current config for diffing
+config = os.path.join(d.getVar("B"), "CMakeCache.txt")
+if os.path.exists(config):
+shutil.copy(config, config + ".orig")
+
+oe_terminal(d.expand("ccmake ${OECMAKE_GENERATOR_ARGS} 
${OECMAKE_SOURCEPATH} -Wno-dev"),
+d.getVar("PN") + " - ccmake", d)
+
+if os.path.exists(config) and os.path.exists(config + ".orig"):
+if bb.utils.md5_file(config) != bb.utils.md5_file(config + ".orig"):
+# the cmake class uses cmake --build, which will by default
+# regenerate configuration, simply mark the compile step as tainted
+# to ensure it is re-run
+bb.note("Configuration changed, recompile will be forced")
+bb.build.write_taint('do_compile', d)
+
+}
+do_ccmake[depends] += "cmake-native:do_populate_sysroot"
+do_ccmake[nostamp] = "1"
+do_ccmake[dirs] = "${B}"
+addtask ccmake after do_configure
+
+def cmake_parse_config_cache(path):
+with open(path, "r") as f:
+for i in f:
+i = i.rstrip("\n")
+if len(i) == 0 or i.startswith("//") or i.startswith("#"):
+continue # empty or comment
+key, value = i.split("=", 1)
+key, keytype = key.split(":")
+if keytype in ["INTERNAL", "STATIC"]:
+continue # skip internal and static config options
+yield key, keytype, value
+
+def cmake_diff_config_vars(a, b):
+removed, added = [], []
+
+for ak, akt, av in a:
+found = False
+for bk, bkt, bv in b:
+if bk == ak:
+found = True
+if bkt != akt or bv != av: # changed
+removed.append((ak, akt, av))
+added.append((bk, bkt, bv))
+break
+# remove any missing from b
+if not found:
+removed.append((ak, akt, av))
+
+# add any missing from a
+for bk, bkt, bv in b:
+if not any(bk == ak for ak, akt, av in a):
+added.append((bk, bkt, bv))
+
+return removed, added
+
+python do_ccmake_diffconfig() {
+import shutil
+config = os.path.join(d.getVar("B"), "CMakeCache.txt")
+if os.path.exists(config) and os.path.exists(config + ".orig"):
+if bb.utils.md5_file(config) != bb.utils.md5_file(config + ".orig"):
+# scan the changed options
+old = list(cmake_parse_config_cache(config + ".orig"))
+new = list(cmake_parse_config_cache(config))
+_, added = cmake_diff_config_vars(old, new)
+
+if len(added) != 0:
+with open(d.expand("${WORKDIR}/configuration.inc"), "w") as f:
+f.write("EXTRA_OECMAKE += \" \\\n")
+for k, kt, v in added:
+escaped = v if " " not in v else "\"{0}\"".format(v)
+f.write("-D{0}:{1}={2} \\\n".format(k, kt, 
escaped))
+f.write("\"\n")
+bb.plain("Configuration recipe fragment written to: 
{0}".format(d.expand("${WORKDIR}/configuration.inc")))
+
+with open(d.expand("${WORKDIR}/site-file.cmake"), "w") as f:
+for k, kt, v in added:
+f.write("SET({0} \"{1}\" CACHE {2} "")\n".format(k, v, 
kt))
+ 

[OE-core] [PATCH v2 3/3] devtool: standard: Handle exporting generated config fragments

[Nathan Rossi]

The cml1 and ccmake bbclasses generate configuration fragment source
files that must be exported from the WORKDIR as a source file to be
preserved across builds. This change adds detection of the current
recipes inherited classes and for cml1 and ccmake classes checks for the
specific generated configuration fragment files. These files are then
exported by devtool and included as SRC_URI files from within the target
layer.

Signed-off-by: Nathan Rossi 
---
Changes in v2:
- None
---
 scripts/lib/devtool/standard.py | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index ea09bbff31..0a1e329e61 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -1328,6 +1328,20 @@ def _export_local_files(srctree, rd, destdir, 
srctreebase):
 if os.path.exists(os.path.join(local_files_dir, fragment_fn)):
 os.unlink(os.path.join(local_files_dir, fragment_fn))
 
+# Special handling for cml1, ccmake, etc bbclasses that generated
+# configuration fragment files that are consumed as source files
+for frag_class, frag_name in [("cml1", "fragment.cfg"), ("ccmake", 
"site-file.cmake")]:
+if bb.data.inherits_class(frag_class, rd):
+srcpath = os.path.join(rd.getVar('WORKDIR'), frag_name)
+if os.path.exists(srcpath):
+if frag_name not in new_set:
+new_set.append(frag_name)
+# copy fragment into destdir
+shutil.copy2(srcpath, destdir)
+# copy fragment into local files if exists
+if os.path.isdir(local_files_dir):
+shutil.copy2(srcpath, local_files_dir)
+
 if new_set is not None:
 for fname in new_set:
 if fname in existing_files:
---
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 1/3] cmake-native: Enable ccmake by default and depend on ncurses

[Nathan Rossi]

Enable the building of the curses based ui for cmake. This depends on
ncurses.

Signed-off-by: Nathan Rossi 
---
This patch suggests enabling this in the cmake-native recipe, however
this might be undesirable for bootstrapping reasons. Whilst ccmake is
not used normally the added dependency on ncurses is likely required for
other parts of the build so impact on build ordering and time should be
relatively minimal.

Changes in v2:
- None
---
 meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
index fedcf3d4bd..b2952ee5f5 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
@@ -1,7 +1,7 @@
 require cmake.inc
 inherit native
 
-DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native 
curl-native"
+DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native 
curl-native ncurses-native"
 
 SRC_URI += "file://OEToolchainConfig.cmake \
 file://environment.d-cmake.sh \
@@ -13,10 +13,9 @@ SRC_URI += "file://OEToolchainConfig.cmake \
 B = "${WORKDIR}/build"
 do_configure[cleandirs] = "${B}"
 
-# Disable ccmake since we don't depend on ncurses
 CMAKE_EXTRACONF = "\
 -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
--DBUILD_CursesDialog=0 \
+-DBUILD_CursesDialog=1 \
 -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
 -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
 -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \
---
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] ccmake.bbclass: Create a cml1 style class for the CMake curses UI

[Nathan Rossi]

On Tue, 2 Apr 2019 at 18:22, Nathan Rossi  wrote:
>
> The ccmake bbclass implements two tasks. The first task 'ccmake'
> preserves the configured state of CMakeCache.txt (generated from the
> configure task) and invokes the 'ccmake' program within a oe_terminal
> execution. The user can then review, select and modify configuration
> options and once satisfied with the configuration exit ccmake. Once
> ccmake has exited the build can be run and the updated configuration
> should be reflected in the output build.
>
> The ccmake bbclass has a second task 'ccmake_diffconfig' to compute the
> differences in configuration which was modified by ccmake. Since there
> are many ways to persist the configuration changes within recipes and
> layer configuration, the differences are emitted as a bitbake recipe
> fragment (configuration.inc) using EXTRA_OECMAKE as well as a CMake
> script file which can be used as a input to cmake via the '-C' argument.
> Both files are generated in the WORKDIR of the build and the paths to
> the files are written as output from the build. It is then up to the
> user to take this configuration and apply it to the desired location.
>
> Signed-off-by: Nathan Rossi 
> ---
>  meta/classes/ccmake.bbclass | 97 
> +
>  1 file changed, 97 insertions(+)
>  create mode 100644 meta/classes/ccmake.bbclass
>
> diff --git a/meta/classes/ccmake.bbclass b/meta/classes/ccmake.bbclass
> new file mode 100644
> index 00..933e122b35
> --- /dev/null
> +++ b/meta/classes/ccmake.bbclass
> @@ -0,0 +1,97 @@
> +inherit terminal
> +
> +python do_ccmake() {
> +import shutil
> +
> +# copy current config for diffing
> +config = os.path.join(d.getVar("B"), "CMakeCache.txt")
> +if os.path.exists(config):
> +shutil.copy(config, config + ".orig")
> +
> +oe_terminal(d.expand("ccmake ${OECMAKE_GENERATOR_ARGS} 
> ${OECMAKE_SOURCEPATH} -Wno-dev"),
> +d.getVar("PN") + " - ccmake", d)
> +
> +if os.path.exists(config) and os.path.exists(config + ".orig"):
> +if bb.utils.md5_file(config) != bb.utils.md5_file(config + ".orig"):
> +# the cmake class uses cmake --build, which will by default
> +# regenerate configuration, simply mark the compile step as 
> tainted
> +# to ensure it is re-run
> +bb.note("Configuration changed, recompile will be forced")
> +bb.build.write_taint('do_compile', d)
> +
> +}
> +do_ccmake[depends] += "cmake-native:do_populate_sysroot"
> +do_ccmake[nostamp] = "1"
> +do_ccmake[dirs] = "${B}"
> +addtask ccmake after do_configure
> +
> +def cmake_parse_config_cache(path):
> +with open(path, "r") as f:
> +for i in f:
> +i = i.rstrip("\n")
> +if len(i) == 0 or i.startswith("//") or i.startswith("#"):
> +continue # empty or comment
> +key, value = i.split("=", 1)
> +key, keytype = key.split(":")
> +if keytype in ["INTERNAL", "STATIC"]:
> +continue # skip internal and static config options
> +yield key, keytype, value
> +
> +def cmake_diff_config_vars(a, b):
> +removed, added = [], []
> +
> +for ak, akt, av in a:
> +found = False
> +for bk, bkt, bv in b:
> +if bk == ak:
> +found = True
> +if bkt != akt or bv != av: # changed
> +removed.append((ak, akt, av))
> +added.append((bk, bkt, bv))
> +break
> +# remove any missing from b
> +if not found:
> +removed.append((ak, akt, av))
> +
> +# add any missing from a
> +for bk, bkt, bv in b:
> +if not any(bk == ak for ak, akt, av in a):
> +added.append((bk, bkt, bv))
> +
> +return removed, added
> +
> +python do_ccmake_diffconfig() {
> +import shutil
> +config = os.path.join(d.getVar("B"), "CMakeCache.txt")
> +if os.path.exists(config) and os.path.exists(config + ".orig"):
> +if bb.utils.md5_file(config) != bb.utils.md5_file(config + ".orig"):
> +# scan the changed options
> +old = list(cmake_parse_config_cache(config + ".orig"))
> +new = list(cmake_parse_config_cache(config))
> +_, added = cmake_diff_config_vars(old, new)
> +
> +if len(added) != 0:
> +with open(d.expand("${WORKDIR}/configuration.inc"), "w") as 
> f:
> +f.write("EXTRA_OECMAKE += \" \\\n")
> +for k, kt, v in added:
> +escaped = v if " " not in v else "\"{0}\"".format(v)
> +f.write("-D{0}:{1}={2} \\\n".format(k, kt, 
> escaped))
> +f.write("\"\n")
> +bb.plain("Configuration recipe fragment written to: 
> {0}".format(d.expand("${WORKDIR}/configuration.inc")))
> +
> +with open(d.expand("${WORKDIR}/site-file.cmake"), 

Re: [OE-core] [oe] Git commit process question.

[Jon Mason]

On Wed, Apr 3, 2019 at 7:45 AM Tom Rini  wrote:
>
> On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
> >
> >
> > On 4/2/19 12:47 PM, Tom Rini wrote:
> > > On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
> > >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  
> > >> wrote:
> > >>> On 4/1/19 6:20 PM, akuster808 wrote:
> > 
> >  On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >> Hello,
> > >>
> > >> I have noticed a large number of git commits with no header
> > >> information being accepted.
> > > Can you be more specific about what "no header information" means? You
> > > mean a shortlog and no full log message?
> >  Commits with just a "subject" and signoff. No additional information
> > >>> If you can convey the reason for the change in just the subject, that is
> > >>> acceptable.. but there is -always- supposed to be a signed-off-by line 
> > >>> according
> > >>> to our guidelines.
> > >>>
> > >>> So if you see this, I think we need to step back and figure out where 
> > >>> and why
> > >>> it's happening and get it resolved in the future.
> > >>>
> > >>> (Places I've seen in the past were one-off mistakes and clearly that -- 
> > >>> so it
> > >>> wasn't anything that we needed to work on a correction.)
> > >>>
> > >>> --Mark
> > >>>
> >  We tend to reference back to how the kernel does things.
> > 
> >  https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> >  These two sections in particular.
> > 
> > 
> >  2) Describe your changes
> > 
> >  Describe your problem. Whether your patch is a one-line bug fix or 
> >  5000 lines of
> >  a new feature, there must be an underlying problem that motivated you 
> >  to do this
> >  work. Convince the reviewer that there is a problem worth fixing and 
> >  that it
> >  makes sense for them to read past the first paragraph.
> > 
> > 
> >  along with this section.
> > 
> > 
> >  14) The canonical patch format
> > 
> >  This section describes how the patch itself should be formatted. Note 
> >  that, if
> >  you have your patches stored in a |git| repository, proper patch 
> >  formatting can
> >  be had with |git format-patch|. The tools cannot create the necessary 
> >  text,
> >  though, so read the instructions below anyway.
> > 
> >  The canonical patch subject line is:
> > 
> >  Subject: [PATCH 001/123] subsystem: summary phrase
> > 
> >  The canonical patch message body contains the following:
> > 
> >    * A |from| line specifying the patch author, followed by an 
> >  empty line
> >  (only needed if the person sending the patch is not the 
> >  author).
> >    * The body of the explanation, line wrapped at 75 columns, which 
> >  will be
> >  copied to the permanent changelog to describe this patch.
> >    * An empty line.
> >    * The |Signed-off-by:| lines, described above, which will also 
> >  go in the
> >  changelog.
> >    * A marker line containing simply |---|.
> >    * Any additional comments not suitable for the changelog.
> >    * The actual patch (|diff| output).
> > 
> > 
> >  - Armin
> > >> There are existing git hooks that can be used to detect and fail to
> > >> merge patches like this.  For Linux, I have the following in
> > >> .git/hooks/pre-commit
> > >> #!/bin/sh
> > >> exec git diff --cached | scripts/checkpatch.pl -
> > > FWIW, over in U-Boot land I do:
> > > ./scripts/checkpatch.pl -q --git origin/master..
> > > as part of checking things prior to pushing to master.
> > Having hooks is fine but after the fact. It puts the burden back on the
> > Layer maintainer to resolve. If we think more info is better, it needs
> > to happen at time of change submittal.
>
> Note that I'm not talking about a hook, I'm talking about what's part of
> my CI process.  And when something pops up there is when I grab the
> patch in question and push back on the submitter.

Exactly!  I do the same things for the Linux stuff I own.  I'll do a
git-am, then redir the output and publicly shame them.  Public shaming
is a vastly underrated method of behavior modification.

Thanks,
Jon

>
> --
> Tom
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][master][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk

[Jaewon Lee]

Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all nativesdk*
sstate into esdk
Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation

Signed-off-by: Jaewon Lee 
---
 meta/classes/populate_sdk_ext.bbclass | 28 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 ++--
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 40b0375..d98b0e5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
 SDK_EXT_TYPE ?= "full"
 SDK_INCLUDE_PKGDATA ?= "0"
 SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else 
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
 
 SDK_RECRDEP_TASKS ?= ""
 
@@ -401,9 +402,27 @@ python copy_buildsystem () {
 excluded_targets = get_sdk_install_targets(d, images_only=True)
 sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
 lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') + 
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+excluded_targets.split(),
+nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+sigfile,
+nativesigfile_pruned,
+sigfile)
+
 oe.copy_buildsystem.prune_lockedsigs([],
  excluded_targets.split(),
  sigfile,
+ False,
  lockedsigs_pruned)
 
 sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
 
 sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
 sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and 
not sdk_include_nativesdk:
 # Create the filtered task list used to generate the sstate cache 
shipped with the SDK
 tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
@@ -658,9 +677,16 @@ fakeroot python do_populate_sdk_ext() {
 d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
 # ESDKs have a libc from the buildtools so ensure we don't ship linguas 
twice
 d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
 populate_sdk_common(d)
 }
 
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
 def get_ext_sdk_depends(d):
 # Note: the deps varflag is a list not a string, so we need to specify 
expand=False
 deps = d.getVarFlag('do_image_complete', 'deps', False)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 7cb784c..5bc728e 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -168,7 +168,7 @@ def generate_locked_sigs(sigfile, d):
 tasks = ['%s.%s' % (v[2], v[1]) for v in depd.values()]
 bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
 
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, 
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, 
pruned_output):
 with open(lockedsigs, 'r') as infile:
 bb.utils.mkdirhier(os.path.dirname(pruned_output))
 with open(pruned_output, 'w') as f:
@@ -178,7 +178,11 @@ def prune_lockedsigs(excluded_tasks, excluded_targets, 
lockedsigs, pruned_output
 if line.endswith('\\\n'):
 splitval = line.strip().split(':')
 if not splitval[1] in excluded_tasks and not 
splitval[0] in excluded_targets:
-

Re: [OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized

[Changqing Li]

On 4/2/19 7:31 PM, Adrian Bunk wrote:

On Tue, Apr 02, 2019 at 05:08:33PM +0800, changqing...@windriver.com wrote:

From: Changqing Li 

fix below compile error with -Werror=maybe-uninitialized

| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error: 
'gltype' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|  *out_gltype = gltype;
|  ^~~~
| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error: 
'glintformat' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|  *out_glintformat = glintformat;
|  ~^
...

Looking at the code, is this a failure that only happens with DEBUG_FLAGS?

Yes, only happen with DEBUG_FLAGS
  

+--- a/cogl/driver/gl/gles/cogl-driver-gles.c
 b/cogl/driver/gl/gles/cogl-driver-gles.c
+@@ -74,9 +74,9 @@ _cogl_driver_pixel_format_to_gl (CoglContext *context,
+  GLenum *out_gltype)
+ {
+   CoglPixelFormat required_format;
+-  GLenum glintformat;
++  GLenum glintformat = 0;
+   GLenum glformat = 0;
+-  GLenum gltype;
++  GLenum gltype = 0;
...

Assigning random values to variables is a bug,
they do not even seem to be valid values for these variables.


According to code logic,  glformat and glintformat will assigned 
simultaneously and usually with same value,


and 0 mean invalid pixel format.

[snip]

    case COGL_PIXEL_FORMAT_DEPTH_24_STENCIL_8:
  glintformat = GL_DEPTH_STENCIL;
  glformat = GL_DEPTH_STENCIL;
  gltype = GL_UNSIGNED_INT_24_8;
  break;

and for gtype, there also should be no problem according to the code logic.

and the fix is just for eliminate the error when DEBUG_FLAGS is enabled.



cu
Adrian


--
BRs

Sandy(Li Changqing)

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] Git commit process question.

[Tom Rini]

On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
> 
> 
> On 4/2/19 12:47 PM, Tom Rini wrote:
> > On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
> >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  wrote:
> >>> On 4/1/19 6:20 PM, akuster808 wrote:
> 
>  On 4/1/19 4:02 PM, Richard Purdie wrote:
> > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >> Hello,
> >>
> >> I have noticed a large number of git commits with no header
> >> information being accepted.
> > Can you be more specific about what "no header information" means? You
> > mean a shortlog and no full log message?
>  Commits with just a "subject" and signoff. No additional information
> >>> If you can convey the reason for the change in just the subject, that is
> >>> acceptable.. but there is -always- supposed to be a signed-off-by line 
> >>> according
> >>> to our guidelines.
> >>>
> >>> So if you see this, I think we need to step back and figure out where and 
> >>> why
> >>> it's happening and get it resolved in the future.
> >>>
> >>> (Places I've seen in the past were one-off mistakes and clearly that -- 
> >>> so it
> >>> wasn't anything that we needed to work on a correction.)
> >>>
> >>> --Mark
> >>>
>  We tend to reference back to how the kernel does things.
> 
>  https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>  These two sections in particular.
> 
> 
>  2) Describe your changes
> 
>  Describe your problem. Whether your patch is a one-line bug fix or 5000 
>  lines of
>  a new feature, there must be an underlying problem that motivated you to 
>  do this
>  work. Convince the reviewer that there is a problem worth fixing and 
>  that it
>  makes sense for them to read past the first paragraph.
> 
> 
>  along with this section.
> 
> 
>  14) The canonical patch format
> 
>  This section describes how the patch itself should be formatted. Note 
>  that, if
>  you have your patches stored in a |git| repository, proper patch 
>  formatting can
>  be had with |git format-patch|. The tools cannot create the necessary 
>  text,
>  though, so read the instructions below anyway.
> 
>  The canonical patch subject line is:
> 
>  Subject: [PATCH 001/123] subsystem: summary phrase
> 
>  The canonical patch message body contains the following:
> 
>    * A |from| line specifying the patch author, followed by an empty 
>  line
>  (only needed if the person sending the patch is not the author).
>    * The body of the explanation, line wrapped at 75 columns, which 
>  will be
>  copied to the permanent changelog to describe this patch.
>    * An empty line.
>    * The |Signed-off-by:| lines, described above, which will also go 
>  in the
>  changelog.
>    * A marker line containing simply |---|.
>    * Any additional comments not suitable for the changelog.
>    * The actual patch (|diff| output).
> 
> 
>  - Armin
> >> There are existing git hooks that can be used to detect and fail to
> >> merge patches like this.  For Linux, I have the following in
> >> .git/hooks/pre-commit
> >> #!/bin/sh
> >> exec git diff --cached | scripts/checkpatch.pl -
> > FWIW, over in U-Boot land I do:
> > ./scripts/checkpatch.pl -q --git origin/master..
> > as part of checking things prior to pushing to master.
> Having hooks is fine but after the fact. It puts the burden back on the
> Layer maintainer to resolve. If we think more info is better, it needs
> to happen at time of change submittal.

Note that I'm not talking about a hook, I'm talking about what's part of
my CI process.  And when something pops up there is when I grab the
patch in question and push back on the submitter.

-- 
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] insane.bbclass: fix QA-check to consider the PREFERRED_RPROVIDER for RDEPENDS

[Catalin Dan Udma]

Ping.

Thanks,
Catalin Udma

> -Original Message-
> From: Catalin Dan Udma
> Sent: Tuesday, March 5, 2019 3:36 PM
> To: Openembedded-core@lists.openembedded.org
> Cc: Catalin Dan Udma 
> Subject: [OE-core][PATCH] insane.bbclass: fix QA-check to consider the
> PREFERRED_RPROVIDER for RDEPENDS
> 
> QA-check looks in the RDEPENDS list without taking into consideration that a
> specific package may have a PREFERRED_RPROVIDER defined.
> If PREFERRED_RPROVIDER is set, QA-check will ignore that settings and will
> consider the original package, resulting in QA-check errors:
>   ERROR: do_packate_qa: QA Issue: <...>, but no providers found in
>   RDEPENDS_? [file-rdeps]
> The fix is to replace the original package in the QA-check with the new
> package defined in PREFERRED_RPROVIDER, if it’s set.
> 
> Signed-off-by: Catalin Udma 
> ---
>  meta/classes/insane.bbclass | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 6411884..165233b 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -689,6 +689,9 @@ def package_qa_check_rdepends(pkg, pkgdest, skip,
> taskdeps, packages, d):
>  # Now do the sanity check!!!
>  if "build-deps" not in skip:
>  for rdepend in rdepends:
> +pref_rdepend = localdata.getVar("PREFERRED_RPROVIDER_%s" %
> rdepend)
> +if pref_rdepend:
> +rdepend = pref_rdepend
>  if "-dbg" in rdepend and "debug-deps" not in skip:
>  error_msg = "%s rdepends on %s" % (pkg,rdepend)
>  package_qa_handle_error("debug-deps", error_msg, d)
> @@ -739,6 +742,9 @@ def package_qa_check_rdepends(pkg, pkgdest, skip,
> taskdeps, packages, d):
>  while next:
>  new = []
>  for rdep in next:
> +pref_rdep = 
> localdata.getVar("PREFERRED_RPROVIDER_%s" %
> rdep)
> +if pref_rdep:
> +rdep = pref_rdep
>  rdep_data = oe.packagedata.read_subpkgdata(rdep, d)
>  sub_rdeps = rdep_data.get("RDEPENDS_" + rdep)
>  if not sub_rdeps:
> --
> 2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/6] Revert "arch-armv5-dsp.inc: Check for dsp only to enable 'e' in package arches"

[Peter Kjellerstedt]

This revert (and the following) are there to allow my alternative 
solution to be applied.

//Peter

> -Original Message-
> From: akuster808 
> Sent: den 2 april 2019 22:53
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/6] Revert "arch-armv5-dsp.inc: Check
> for dsp only to enable 'e' in package arches"
> 
> Peter
> 
> On 4/2/19 12:31 PM, Peter Kjellerstedt wrote:
> > This reverts commit 1d6d5bb30a83f9136b7c33e297d48564ae61b50e.
> 
> What problem are you seeing that is being fixed by this revert?
> it may help decide if it need to be in warrior.
> 
> - armin
> >
> > Signed-off-by: Peter Kjellerstedt 
> > ---
> >  meta/conf/machine/include/arm/arch-armv5-dsp.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> > index d117af1520..1f16085fcd 100644
> > --- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> > +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> > @@ -1,4 +1,4 @@
> > -ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'dsp' ],
> 'e', '', d)}"
> > +ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5',
> 'dsp' ], 'e', '', d)}"
> >  TUNEVALID[dsp] = "ARM DSP functionality"
> >
> >  require conf/machine/include/arm/arch-armv5.inc

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings

[Peter Kjellerstedt]

> -Original Message-
> From: Richard Purdie 
> Sent: den 2 april 2019 22:27
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
> 
> On Tue, 2019-04-02 at 21:30 +0200, Peter Kjellerstedt wrote:
> > These patches are intended to improve the ARM tunings and came about
> > after I had to study the tune files a lot more than I first had
> > anticipated...
> >
> > The first patch (arch-armv8a.inc: Correct
> > PACKAGE_EXTRA_ARCHS_tune-armv8a-*) avoids odd architectures such as
> > "crc" and "crypto" to be included in PACKAGE_EXTRA_ARCHS.
> >
> > The following three patches (where i have sent the latter two to the
> > list before) restores the "armv*" features to TUNE_FEATURES for all
> > ARM based SoCs as it does not make sense to remove them from the SoC
> > specific tune files just to determine whether -mcpu or -march shall
> > be used. This is because the SoCs still support the armv* features
> > specified in their TUNE_FEATURES even if they also have more specific
> > SoC tunings.
> 
> It depends how you view TUNE_FEATURES and what the presence of things
> there is defined to mean.

The assumption I made was that the features listed in TUNE_FEATURES 
matches what features the compiler/linker will make use of when 
building the code and something that can be checked by, e.g., recipes 
to enable/disable functionality to match this. There are examples of 
this in the recipes in OE-Core, e.g., where TUNE_FEATURES is checked 
to determine what options to pass to configure.

E.g., with DEFAULTTUNE set to "arm926ejs", TUNE_FEATURES expands to 
"arm armv5 thumb dsp arm926ejs" (with Thud and older, or with my 
patches applied). To me this means that I can assume that I can use 
anything that is specific to either of those features when I decide 
what to build. And although arm926ejs implies armv5, having the 
latter as a separate feature makes it possible to write a generic 
test for armv5 without having to know the exact SoC and what it 
supports.

> "armv4t" is defined in the arm tune files to mean "add -march=armv4t"
> which is the convention used throughout all the tune files.

I fail to see where it says that the "armv*" features of TUNE_FEATUES 
are to be used to set -march and nothing else. That seems like a very 
odd implication of one of the many features specified in TUNE_FEATURES.

However, with my patches applied, the "armv*" features still says to 
set -march, unless there is also a more specific tune feature, e.g., 
"arm926ejs", which means -mcpu will be used instead. I don't think 
deciding between -mcpu and -march should be based on the existence or 
non-existence of a given feature in TUNE_FEATURES, but rather on the 
context. This also matches how the TUNE_FEATURES_tune-arm* variables 
are being defined with more specific variables such as 
TUNE_FEATURES_tune-arm926ejs being defined based on more generic 
variables (TUNE_FEATURES_tune-armv5te in this case) and then adding 
the more specific feature(s).

> I'm still not convinced this part of your changes improves the
> situation as it then breaks and confuses that situation.

According to my view there is less confusion now. TUNE_FEATURES yet 
again describes the features that are supported.

> I'm also worried you're wanting this as you have code elsewhere which
> is using "armvX" there to mean something else?

Actually we're not using any such tests. I did the initial rework 
based on the notion that the change that had gone into the tuning 
files felt wrong, tearing out the structure that was previously 
there in the definitions of the TUNE_FEATURES_tune-arm* variables, 
and how it had messed up my view of what the features in 
TUNE_FEATURES are supposed to mean. And after having studied those 
files a lot more, that initial notion still holds true for me.

> Cheers,
> 
> Richard

//Peter

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] perl: Don't use TARGET_ARCH in filepaths

[William A. Kennington III via Openembedded-core]

Platforms like powerpc64le have different variants of the same target.
Perl guesses that the target should be called powerpc64le-linux, while
TARGET_ARCH think it is called ppc64le-linux. If we use TARGET_ARCH
for perl-native on powerpc64le this build will fail since the
post-install rm command won't reference and existing file.

We know that there is only one arch existing per build, so use a
wildcard for finding the path instead of trying to guess the correct
architecture name.

Signed-off-by: William A. Kennington III 
---
 meta/recipes-devtools/perl-sanity/perl_5.28.1.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb 
b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
index 5aa7cd3ee1..f3948a5f8d 100644
--- a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
+++ b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
@@ -107,8 +107,8 @@ do_install() {
 install lib/ExtUtils/typemap ${D}${libdir}/perl5/${PV}/ExtUtils/
 
 # Fix up shared library
-rm ${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so
-ln -sf ../../../../libperl.so.${PERL_LIB_VER} 
${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so
+rm ${D}/${libdir}/perl5/${PV}/*/CORE/libperl.so
+ln -sf ../../../../libperl.so.${PERL_LIB_VER} $(echo 
${D}/${libdir}/perl5/${PV}/*/CORE)/libperl.so
 }
 
 do_install_append_class-target() {
-- 
2.21.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] Git commit process question.

[akuster808]

On 4/2/19 12:47 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
>> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  wrote:
>>> On 4/1/19 6:20 PM, akuster808 wrote:

 On 4/1/19 4:02 PM, Richard Purdie wrote:
> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>> Hello,
>>
>> I have noticed a large number of git commits with no header
>> information being accepted.
> Can you be more specific about what "no header information" means? You
> mean a shortlog and no full log message?
 Commits with just a "subject" and signoff. No additional information
>>> If you can convey the reason for the change in just the subject, that is
>>> acceptable.. but there is -always- supposed to be a signed-off-by line 
>>> according
>>> to our guidelines.
>>>
>>> So if you see this, I think we need to step back and figure out where and 
>>> why
>>> it's happening and get it resolved in the future.
>>>
>>> (Places I've seen in the past were one-off mistakes and clearly that -- so 
>>> it
>>> wasn't anything that we needed to work on a correction.)
>>>
>>> --Mark
>>>
 We tend to reference back to how the kernel does things.

 https://www.kernel.org/doc/html/latest/process/submitting-patches.html
 These two sections in particular.


 2) Describe your changes

 Describe your problem. Whether your patch is a one-line bug fix or 5000 
 lines of
 a new feature, there must be an underlying problem that motivated you to 
 do this
 work. Convince the reviewer that there is a problem worth fixing and that 
 it
 makes sense for them to read past the first paragraph.


 along with this section.


 14) The canonical patch format

 This section describes how the patch itself should be formatted. Note 
 that, if
 you have your patches stored in a |git| repository, proper patch 
 formatting can
 be had with |git format-patch|. The tools cannot create the necessary text,
 though, so read the instructions below anyway.

 The canonical patch subject line is:

 Subject: [PATCH 001/123] subsystem: summary phrase

 The canonical patch message body contains the following:

   * A |from| line specifying the patch author, followed by an empty 
 line
 (only needed if the person sending the patch is not the author).
   * The body of the explanation, line wrapped at 75 columns, which 
 will be
 copied to the permanent changelog to describe this patch.
   * An empty line.
   * The |Signed-off-by:| lines, described above, which will also go in 
 the
 changelog.
   * A marker line containing simply |---|.
   * Any additional comments not suitable for the changelog.
   * The actual patch (|diff| output).


 - Armin
>> There are existing git hooks that can be used to detect and fail to
>> merge patches like this.  For Linux, I have the following in
>> .git/hooks/pre-commit
>> #!/bin/sh
>> exec git diff --cached | scripts/checkpatch.pl -
> FWIW, over in U-Boot land I do:
> ./scripts/checkpatch.pl -q --git origin/master..
> as part of checking things prior to pushing to master.
Having hooks is fine but after the fact. It puts the burden back on the
Layer maintainer to resolve. If we think more info is better, it needs
to happen at time of change submittal.

- armin
>
>



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Git commit process question.

[akuster808]

On 4/2/19 12:46 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
>> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
>>>
>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
 On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> Hello,
>
> I have noticed a large number of git commits with no header
> information being accepted.
 Can you be more specific about what "no header information" means? You
 mean a shortlog and no full log message?
>>> Commits with just a "subject" and signoff. No additional information
>>>
>>> We tend to reference back to how the kernel does things.
>>>
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>> These two sections in particular.
>>>
>>>
>>> 2) Describe your changes
>>>
>>> Describe your problem. Whether your patch is a one-line bug fix or 5000
>>> lines of a new feature, there must be an underlying problem that
>>> motivated you to do this work. Convince the reviewer that there is a
>>> problem worth fixing and that it makes sense for them to read past the
>>> first paragraph.
>>> ...
>> The kernel does not have "upgrade foo to the latest upstream version" 
>> commits.
>>
>> With the Automatic Upgrade Helper this is a semi-automatic task, and 
>> most of the time there is no specific motivation other than upgrading
>> to the latest upstream version.
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?..

Maybe, if someone want to enhance the AUH.

- armin
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/6] Revert "arch-armv5-dsp.inc: Check for dsp only to enable 'e' in package arches"

[akuster808]

Peter

On 4/2/19 12:31 PM, Peter Kjellerstedt wrote:
> This reverts commit 1d6d5bb30a83f9136b7c33e297d48564ae61b50e.

What problem are you seeing that is being fixed by this revert?
it may help decide if it need to be in warrior.

- armin
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/conf/machine/include/arm/arch-armv5-dsp.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc 
> b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> index d117af1520..1f16085fcd 100644
> --- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> @@ -1,4 +1,4 @@
> -ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'dsp' ], 'e', '', 
> d)}"
> +ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 
> 'e', '', d)}"
>  TUNEVALID[dsp] = "ARM DSP functionality"
>  
>  require conf/machine/include/arm/arch-armv5.inc

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings

[Richard Purdie]

On Tue, 2019-04-02 at 21:30 +0200, Peter Kjellerstedt wrote:
> These patches are intended to improve the ARM tunings and came about
> after I had to study the tune files a lot more than I first had
> anticipated...
> 
> The first patch (arch-armv8a.inc: Correct
> PACKAGE_EXTRA_ARCHS_tune-armv8a-*) avoids odd architectures such as
> "crc" and "crypto" to be included in PACKAGE_EXTRA_ARCHS.
> 
> The following three patches (where i have sent the latter two to the
> list before) restores the "armv*" features to TUNE_FEATURES for all ARM
> based SoCs as it does not make sense to remove them from the SoC
> specific tune files just to determine whether -mcpu or -march shall be
> used. This is because the SoCs still support the armv* features
> specified in their TUNE_FEATURES even if they also have more specific
> SoC tunings.

It depends how you view TUNE_FEATURES and what the presence of things 
there is defined to mean.

"armv4t" is defined in the arm tune files to mean "add -march=armv4t"
which is the convention used throughout all the tune files.

I'm still not convinced this part of your changes improves the
situation as it then breaks and confuses that situation.

I'm also worried you're wanting this as you have code elsewhere which
is using "armvX" there to mean something else?

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Git commit process question.

[Tom Rini]

On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  wrote:
> >
> > On 4/1/19 6:20 PM, akuster808 wrote:
> > >
> > >
> > > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >>> Hello,
> > >>>
> > >>> I have noticed a large number of git commits with no header
> > >>> information being accepted.
> > >> Can you be more specific about what "no header information" means? You
> > >> mean a shortlog and no full log message?
> > > Commits with just a "subject" and signoff. No additional information
> >
> > If you can convey the reason for the change in just the subject, that is
> > acceptable.. but there is -always- supposed to be a signed-off-by line 
> > according
> > to our guidelines.
> >
> > So if you see this, I think we need to step back and figure out where and 
> > why
> > it's happening and get it resolved in the future.
> >
> > (Places I've seen in the past were one-off mistakes and clearly that -- so 
> > it
> > wasn't anything that we needed to work on a correction.)
> >
> > --Mark
> >
> > > We tend to reference back to how the kernel does things.
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > > These two sections in particular.
> > >
> > >
> > > 2) Describe your changes
> > >
> > > Describe your problem. Whether your patch is a one-line bug fix or 5000 
> > > lines of
> > > a new feature, there must be an underlying problem that motivated you to 
> > > do this
> > > work. Convince the reviewer that there is a problem worth fixing and that 
> > > it
> > > makes sense for them to read past the first paragraph.
> > >
> > >
> > > along with this section.
> > >
> > >
> > > 14) The canonical patch format
> > >
> > > This section describes how the patch itself should be formatted. Note 
> > > that, if
> > > you have your patches stored in a |git| repository, proper patch 
> > > formatting can
> > > be had with |git format-patch|. The tools cannot create the necessary 
> > > text,
> > > though, so read the instructions below anyway.
> > >
> > > The canonical patch subject line is:
> > >
> > > Subject: [PATCH 001/123] subsystem: summary phrase
> > >
> > > The canonical patch message body contains the following:
> > >
> > >   * A |from| line specifying the patch author, followed by an empty 
> > > line
> > > (only needed if the person sending the patch is not the author).
> > >   * The body of the explanation, line wrapped at 75 columns, which 
> > > will be
> > > copied to the permanent changelog to describe this patch.
> > >   * An empty line.
> > >   * The |Signed-off-by:| lines, described above, which will also go 
> > > in the
> > > changelog.
> > >   * A marker line containing simply |---|.
> > >   * Any additional comments not suitable for the changelog.
> > >   * The actual patch (|diff| output).
> > >
> > >
> > > - Armin
> 
> There are existing git hooks that can be used to detect and fail to
> merge patches like this.  For Linux, I have the following in
> .git/hooks/pre-commit
> #!/bin/sh
> exec git diff --cached | scripts/checkpatch.pl -

FWIW, over in U-Boot land I do:
./scripts/checkpatch.pl -q --git origin/master..
as part of checking things prior to pushing to master.

-- 
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] Git commit process question.

[Tom Rini]

On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> > 
> > 
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >> Hello,
> > >>
> > >> I have noticed a large number of git commits with no header
> > >> information being accepted.
> > > Can you be more specific about what "no header information" means? You
> > > mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
> > 
> > We tend to reference back to how the kernel does things.
> > 
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> > 
> > 
> > 2) Describe your changes
> > 
> > Describe your problem. Whether your patch is a one-line bug fix or 5000
> > lines of a new feature, there must be an underlying problem that
> > motivated you to do this work. Convince the reviewer that there is a
> > problem worth fixing and that it makes sense for them to read past the
> > first paragraph.
> >...
> 
> The kernel does not have "upgrade foo to the latest upstream version" commits.
> 
> With the Automatic Upgrade Helper this is a semi-automatic task, and 
> most of the time there is no specific motivation other than upgrading
> to the latest upstream version.

But since that's just filling in a template the body can also be a
template perhaps with useful AUH data (run at ... by ... ?) ?

-- 
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 4/6] arm-tunes: Prefer the -mcpu option over -march

[Peter Kjellerstedt]

Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.

The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.

This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-arm.inc   | 6 ++
 meta/conf/machine/include/arm/arch-armv4.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv5.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv6.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc| 2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   | 2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 6 +++---
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc   | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa15.inc | 2 +-
 meta/conf/machine/include/tune-cortexa17.inc | 2 +-
 meta/conf/machine/include/tune-cortexa32.inc | 2 +-
 meta/conf/machine/include/tune-cortexa35.inc | 2 +-
 meta/conf/machine/include/tune-cortexa5.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa53.inc | 2 +-
 meta/conf/machine/include/tune-cortexa7.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa72.inc | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc  | 2 +-
 meta/conf/machine/include/tune-ep9312.inc| 2 +-
 meta/conf/machine/include/tune-iwmmxt.inc| 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-thunderx.inc  | 2 +-
 meta/conf/machine/include/tune-xscale.inc| 2 +-
 26 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc 
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..188cf8b473 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,12 @@ ARMPKGSFX_THUMB ??= ""
 TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 
'arm', d)}"
 TUNE_PKGARCH = 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
+# Prefer -mcpu= over -arch=
+TUNE_CCARGS_MCPU ??= ""
+TUNE_CCARGS_MARCH ??= ""
+TUNE_CCARGS_FEATURES ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_CCARGS_MCPU') or 
d.getVar('TUNE_CCARGS_MARCH')}${TUNE_CCARGS_FEATURES}"
+
 ABIEXTENSION = "eabi"
 
 TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..dac791e308 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_CCARGS_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo 
neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..9c82015df2 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv5"
 
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 TUNECONFLICTS[armv5] = "armv4"
-TUNE_CCARGS .= 

[OE-core] [PATCH 3/6] Revert "arm-tunes: Remove -march option if mcpu is already added"

[Peter Kjellerstedt]

This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.

This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).

An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  4 +---
 meta/conf/machine/include/tune-arm920t.inc   |  4 +---
 meta/conf/machine/include/tune-arm926ejs.inc |  4 +---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  4 +---
 meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa5.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa7.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa8.inc  | 19 +++-
 meta/conf/machine/include/tune-cortexa9.inc  | 28 ++--
 meta/conf/machine/include/tune-ep9312.inc|  1 -
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 +--
 meta/conf/machine/include/tune-xscale.inc|  7 ++
 14 files changed, 76 insertions(+), 109 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc 
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' 
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', 
'armv6:', '' ,d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} 
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc 
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' 
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t 
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc 
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' 
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', 
'armv5:', '' ,d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} 
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc 
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' 
-mcpu=arm9tdmi', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm9tdmi"
 ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"
-# mcpu is used so 

[OE-core] [PATCH 2/6] Revert "arch-armv5-dsp.inc: Check for dsp only to enable 'e' in package arches"

[Peter Kjellerstedt]

This reverts commit 1d6d5bb30a83f9136b7c33e297d48564ae61b50e.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-armv5-dsp.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc 
b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
index d117af1520..1f16085fcd 100644
--- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -1,4 +1,4 @@
-ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'dsp' ], 'e', '', d)}"
+ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 
'e', '', d)}"
 TUNEVALID[dsp] = "ARM DSP functionality"
 
 require conf/machine/include/arm/arch-armv5.inc
-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/6] Correct and improve the ARM tunings

[Peter Kjellerstedt]

These patches are intended to improve the ARM tunings and came about
after I had to study the tune files a lot more than I first had
anticipated...

The first patch (arch-armv8a.inc: Correct
PACKAGE_EXTRA_ARCHS_tune-armv8a-*) avoids odd architectures such as
"crc" and "crypto" to be included in PACKAGE_EXTRA_ARCHS.

The following three patches (where i have sent the latter two to the
list before) restores the "armv*" features to TUNE_FEATURES for all ARM
based SoCs as it does not make sense to remove them from the SoC
specific tune files just to determine whether -mcpu or -march shall be
used. This is because the SoCs still support the armv* features
specified in their TUNE_FEATURES even if they also have more specific
SoC tunings.

The next patch (arch-arm64.inc: Lower the priority of aarch64 in
MACHINEOVERRIDES) makes sure that ${SOC_FAMILY} (if present) and
${MACHINE} have higher override priorities than aarch64, as should be.

Finally, the last patch (arm-tunes: Add armv8a to TUNE_FEATURES as
appropriate) adds the "armv8a" feature to TUNE_FEATURES for the
Cortex-A32, Cortex-A35, Cortex-A53 and Cortex-A72 to match all the other
ARM tunings.

//Peter

The following changes since commit a397fd17e42d745e6a23dee86e82b887f3d25ccd:

  layer.conf: Update to warrior release name series (2019-04-02 15:24:50 +0100)

are available in the git repository at:

  git://push.yoctoproject.org/poky-contrib pkj/arm-tunings

Peter Kjellerstedt (6):
  arch-armv8a.inc: Correct PACKAGE_EXTRA_ARCHS_tune-armv8a-*
  Revert "arch-armv5-dsp.inc: Check for dsp only to enable 'e' in
package arches"
  Revert "arm-tunes: Remove -march option if mcpu is already added"
  arm-tunes: Prefer the -mcpu option over -march
  arch-arm64.inc: Lower the priority of aarch64 in MACHINEOVERRIDES
  arm-tunes: Add armv8a to TUNE_FEATURES as appropriate

 meta/conf/machine/include/arm/arch-arm.inc   |  6 +
 meta/conf/machine/include/arm/arch-arm64.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv4.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv5-dsp.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv5.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv6.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc|  2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   |  2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 12 +-
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  6 ++---
 meta/conf/machine/include/tune-arm920t.inc   |  6 ++---
 meta/conf/machine/include/tune-arm926ejs.inc |  6 ++---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  6 ++---
 meta/conf/machine/include/tune-cortexa15.inc | 29 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 29 ++-
 meta/conf/machine/include/tune-cortexa32.inc | 11 -
 meta/conf/machine/include/tune-cortexa35.inc |  6 ++---
 meta/conf/machine/include/tune-cortexa5.inc  | 29 ++-
 meta/conf/machine/include/tune-cortexa53.inc | 10 
 meta/conf/machine/include/tune-cortexa7.inc  | 29 ++-
 meta/conf/machine/include/tune-cortexa72.inc |  6 ++---
 meta/conf/machine/include/tune-cortexa8.inc  | 21 +++--
 meta/conf/machine/include/tune-cortexa9.inc  | 30 ++--
 meta/conf/machine/include/tune-ep9312.inc|  3 +--
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  5 ++--
 meta/conf/machine/include/tune-thunderx.inc  |  2 +-
 meta/conf/machine/include/tune-xscale.inc|  9 +++
 28 files changed, 125 insertions(+), 153 deletions(-)

-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 6/6] arm-tunes: Add armv8a to TUNE_FEATURES as appropriate

[Peter Kjellerstedt]

This adds the armv8a tuning for Cortex-A32, Cortex-A35, Cortex-A53 and
Cortex-A72. This matches the other ARM tunes.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-cortexa32.inc | 9 -
 meta/conf/machine/include/tune-cortexa35.inc | 4 ++--
 meta/conf/machine/include/tune-cortexa53.inc | 8 
 meta/conf/machine/include/tune-cortexa72.inc | 4 ++--
 4 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa32.inc 
b/meta/conf/machine/include/tune-cortexa32.inc
index c50470203c..a150540845 100644
--- a/meta/conf/machine/include/tune-cortexa32.inc
+++ b/meta/conf/machine/include/tune-cortexa32.inc
@@ -1,6 +1,5 @@
 DEFAULTTUNE ?= "cortexa32"
 
-
 TUNEVALID[cortexa32] = "Enable Cortex-A32 specific processor optimizations"
 TUNE_CCARGS_MCPU .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa32', ' 
-mcpu=cortex-a32', '', d)}"
 
@@ -8,10 +7,10 @@ require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
 AVAILTUNES += "cortexa32 cortexa32-crypto"
-ARMPKGARCH_tune-cortexa32 = "cortexa32"
-ARMPKGARCH_tune-cortexa32-crypto  = "cortexa32"
-TUNE_FEATURES_tune-cortexa32  = "aarch64 cortexa32 crc"
-TUNE_FEATURES_tune-cortexa32-crypto   = "aarch64 cortexa32 crc crypto"
+ARMPKGARCH_tune-cortexa32?= "cortexa32"
+ARMPKGARCH_tune-cortexa32-crypto ?= "cortexa32"
+TUNE_FEATURES_tune-cortexa32  = "${TUNE_FEATURES_tune-armv8a-crc} 
cortexa32"
+TUNE_FEATURES_tune-cortexa32-crypto   = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa32"
 PACKAGE_EXTRA_ARCHS_tune-cortexa32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa32"
 PACKAGE_EXTRA_ARCHS_tune-cortexa32-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa32 cortexa32-crypto"
 BASE_LIB_tune-cortexa32   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa35.inc 
b/meta/conf/machine/include/tune-cortexa35.inc
index 0b082ce259..f57b0bd6e9 100644
--- a/meta/conf/machine/include/tune-cortexa35.inc
+++ b/meta/conf/machine/include/tune-cortexa35.inc
@@ -9,8 +9,8 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa35 cortexa35-crypto"
 ARMPKGARCH_tune-cortexa35 = "cortexa35"
 ARMPKGARCH_tune-cortexa35-crypto  = "cortexa35"
-TUNE_FEATURES_tune-cortexa35  = "aarch64 cortexa35 crc"
-TUNE_FEATURES_tune-cortexa35-crypto   = "aarch64 cortexa35 crc crypto"
+TUNE_FEATURES_tune-cortexa35  = "${TUNE_FEATURES_tune-armv8a-crc} 
cortexa35"
+TUNE_FEATURES_tune-cortexa35-crypto   = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa35"
 PACKAGE_EXTRA_ARCHS_tune-cortexa35 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa35"
 PACKAGE_EXTRA_ARCHS_tune-cortexa35-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa35 cortexa35-crypto"
 BASE_LIB_tune-cortexa35   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
index b3bd8bbc4e..48de368328 100644
--- a/meta/conf/machine/include/tune-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -7,10 +7,10 @@ require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
 AVAILTUNES += "cortexa53 cortexa53-crypto"
-ARMPKGARCH_tune-cortexa53 = "cortexa53"
-ARMPKGARCH_tune-cortexa53-crypto  = "cortexa53"
-TUNE_FEATURES_tune-cortexa53  = "aarch64 cortexa53 crc"
-TUNE_FEATURES_tune-cortexa53-crypto   = "aarch64 cortexa53 crc crypto"
+ARMPKGARCH_tune-cortexa53?= "cortexa53"
+ARMPKGARCH_tune-cortexa53-crypto ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53  = "${TUNE_FEATURES_tune-armv8a-crc} 
cortexa53"
+TUNE_FEATURES_tune-cortexa53-crypto   = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto}cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa53 cortexa53-crypto"
 BASE_LIB_tune-cortexa53   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa72.inc 
b/meta/conf/machine/include/tune-cortexa72.inc
index 1ed456f1a9..b527c5abaf 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -7,7 +7,7 @@ require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
 AVAILTUNES += "cortexa72"
-ARMPKGARCH_tune-cortexa72 = "cortexa72"
-TUNE_FEATURES_tune-cortexa72  = "aarch64 cortexa72 crc crypto"
+ARMPKGARCH_tune-cortexa72?= "cortexa72"
+TUNE_FEATURES_tune-cortexa72  = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72"
 BASE_LIB_tune-cortexa72   = "lib64"
-- 
2.12.0

-- 
___
Openembedded-core mailing list

[OE-core] [PATCH 5/6] arch-arm64.inc: Lower the priority of aarch64 in MACHINEOVERRIDES

[Peter Kjellerstedt]

This makes sure, e.g., ${SOC_FAMILY} and ${MACHINE} have higher
priorities than aarch64.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-arm64.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/arch-arm64.inc 
b/meta/conf/machine/include/arm/arch-arm64.inc
index 5f90763f7f..53f4566815 100644
--- a/meta/conf/machine/include/arm/arch-arm64.inc
+++ b/meta/conf/machine/include/arm/arch-arm64.inc
@@ -4,7 +4,7 @@ require conf/machine/include/arm/arch-armv7ve.inc
 
 TUNEVALID[aarch64] = "Enable instructions for aarch64"
 
-MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 
':aarch64', '' ,d)}"
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 
'aarch64:', '' ,d)}"
 
 # Little Endian base configs
 AVAILTUNES += "aarch64 aarch64_be"
-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/6] arch-armv8a.inc: Correct PACKAGE_EXTRA_ARCHS_tune-armv8a-*

[Peter Kjellerstedt]

The armv8a tune specific PACKAGE_EXTRA_ARCHS contained tune feature
names like "crc" and "crypto" rather than package architecture names
like "armv8a-crc" and "armv8a-crypto".

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-armv8a.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
b/meta/conf/machine/include/arm/arch-armv8a.inc
index 44d0ca4557..f810a1e8fc 100644
--- a/meta/conf/machine/include/arm/arch-armv8a.inc
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -21,9 +21,9 @@ TUNE_FEATURES_tune-armv8a-crc  = 
"${TUNE_FEATURES_tune-armv8a} crc"
 TUNE_FEATURES_tune-armv8a-crypto   = "${TUNE_FEATURES_tune-armv8a} 
crypto"
 TUNE_FEATURES_tune-armv8a-crc-crypto   = "${TUNE_FEATURES_tune-armv8a-crc} 
crypto"
 PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a"
-PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
-PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
-PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8a-crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8a-crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} armv8a-crypto armv8a-crc-crypto"
 BASE_LIB_tune-armv8a   = "lib64"
 BASE_LIB_tune-armv8a-crc   = "lib64"
 BASE_LIB_tune-armv8a-crypto= "lib64"
-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2] base.bbclass, staging.bbclass: Move prepare_recipe_sysroot task dependency

[Peter Kjellerstedt]

Move prepare_recipe_sysroot's task dependency on populate_sysroot from
base.bbclass (where it was specified in the middle of do_configure's
definition) to staging.bbclass (where the rest of
do_prepare_recipe_sysroot is defined). This was a left-over from when
recipe specific sysroots were introduced in commit 809746f5 and the
task dependency on populate_sysroot was moved from do_configure to
do_prepare_recipe_sysroot.

Signed-off-by: Peter Kjellerstedt 
---

PATCHv2: Removed the Change-Id footer from the commit message.

 meta/classes/base.bbclass| 1 -
 meta/classes/staging.bbclass | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 8ece51fe42..d0b82d747d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -310,7 +310,6 @@ CLEANBROKEN = "0"
 
 addtask configure after do_patch
 do_configure[dirs] = "${B}"
-do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 base_do_configure() {
if [ -n "${CONFIGURESTAMPFILE}" -a -e "${CONFIGURESTAMPFILE}" ]; then
if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" ]; then
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index c9bcd745fe..062b2817c8 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -577,6 +577,7 @@ python extend_recipe_sysroot() {
 }
 extend_recipe_sysroot[vardepsexclude] += "MACHINE_ARCH PACKAGE_EXTRA_ARCHS 
SDK_ARCH BUILD_ARCH SDK_OS BB_TASKDEPDATA"
 
+do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 python do_prepare_recipe_sysroot () {
 bb.build.exec_func("extend_recipe_sysroot", d)
 }
-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] base.bbclass, staging.bbclass: Move prepare_recipe_sysroot task dependency

[Peter Kjellerstedt]

Move prepare_recipe_sysroot's task dependency on populate_sysroot from
base.bbclass (where it was specified in the middle of do_configure's
definition) to staging.bbclass (where the rest of
do_prepare_recipe_sysroot is defined). This was a left-over from when
recipe specific sysroots were introduced in commit 809746f5 and the
task dependency on populate_sysroot was moved from do_configure to
do_prepare_recipe_sysroot.

Change-Id: I0512991e90d88a86852054062709e8b6aacc61af
Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/base.bbclass| 1 -
 meta/classes/staging.bbclass | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 8ece51fe42..d0b82d747d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -310,7 +310,6 @@ CLEANBROKEN = "0"
 
 addtask configure after do_patch
 do_configure[dirs] = "${B}"
-do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 base_do_configure() {
if [ -n "${CONFIGURESTAMPFILE}" -a -e "${CONFIGURESTAMPFILE}" ]; then
if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" ]; then
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index c9bcd745fe..062b2817c8 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -577,6 +577,7 @@ python extend_recipe_sysroot() {
 }
 extend_recipe_sysroot[vardepsexclude] += "MACHINE_ARCH PACKAGE_EXTRA_ARCHS 
SDK_ARCH BUILD_ARCH SDK_OS BB_TASKDEPDATA"
 
+do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 python do_prepare_recipe_sysroot () {
 bb.build.exec_func("extend_recipe_sysroot", d)
 }
-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [thud][PATCH] Revert "boost: update to 1.69.0"

[akuster808]

On 4/2/19 12:18 AM, Martin Jansa wrote:
> Any update on this one? Or should we downgrade it on our side when
> bumping oe-core/thud revision?
I have this stagged but it missed the QA cutoff. 

- armin
>
> On Sun, Mar 24, 2019 at 7:48 PM Martin Jansa  > wrote:
>
> On Sun, Mar 24, 2019 at 11:45:08AM -0700, akuster808 wrote:
> >
> >
> > On 3/24/19 11:01 AM, Martin Jansa wrote:
> > > On Tue, Mar 19, 2019 at 07:52:06AM +, mikko.rap...@bmw.de
>  wrote:
> > >> On Mon, Mar 18, 2019 at 06:03:05PM +0100, Andreas Müller wrote:
> > >>> On Mon, Mar 18, 2019 at 5:45 PM Armin Kuster
> mailto:akuster...@gmail.com>> wrote:
> >  This reverts commit a384248938ea9db096866bf4ec8678d35ca62a12.
> > 
> >  This package update slipped in doing the maint process.
> Removing it.
> > >> 
> > >>> Just my opinion - don't consider this as NAK.
> > >>>
> > >>> * I already fixed the recipes that failed for me. For at
> least one the
> > >>> change is no more compatible to 1.68.0.
> > >>> * This makes PV going backwards
> > >>>
> > >>> Thanks for addressing - what do others think?
> > >> I'm not using thud yet, but updating boost in stable branch
> would break
> > >> too many things and I would have to revert that change in our
> trees. Some boost
> > >> updates are in the end quite trivial and just require recompiling
> > >> everything but still, I would prefer that boost is not
> updated in stable
> > >> branches unless there is a huge security/stability issue with
> the old version.
> > > Agreed.
> > >
> > > I care less for PV going backwards nowadays, it's probably
> less annoying than
> > > bumping PE first in master and then backporting PE bump to thud.
> > >
> > > People with build issues related to boost upgrade probably never
> > > built whole image to push it as an upgrade to end devices.
> >
> > So do you agree with the revert?
>
> I do.
>
> -- 
> Martin 'JaMa' Jansa     jabber: martin.ja...@gmail.com
> 
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] tzdata: Install everything by default

[Mark Hatle]

On 4/2/19 11:36 AM, Paul Barker wrote:
> On Tue, 2 Apr 2019, at 17:29, Mark Hatle wrote:
>> On 4/2/19 9:15 AM, Paul Barker wrote:
>>> tzdata is converted to an empty meta package which pulls in all
>>> subpackages. The subpackages are defined in a TZ_PACKAGES variable so
>>> that we don't have to repeat ourselves.
>>>
>>> The timezones and conffiles which were in the tzdata package are moved
>>> to a new 'tzdata-core' package.
>>
>> Is there any type of 'RREPLACES' or anything that should be added so previous
>> users of tzdata-all get tzdata in a package upgrade?
> 
> tzdata-all is just what I called it in my first attempt at this patch. So 
> there was never a tzdata-all upstream to my knowledge.
> 

Ahh ok, so then no replacement needed you should be fine.

--Mark
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] asciidoc: specify XML catalogue to use

[Ross Burton]

libxml-native by default uses a XML catalogue at /etc/xml/catalog, instead of
the one in the sysroot.  Until this is fixed (#13260) override the XML catalogue
manually in the recipe to point explicitly at the docbook-xml and docbook-xsl
catalogues.

This fixes either complete build failures (where the host doesn't have
docbook-xml installed) or slow builds (where the host doesn't have docbook-xsl
installed).

Signed-off-by: Ross Burton 
---
 .../asciidoc/asciidoc/auto-catalogs.patch  | 53 ++
 meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb   |  9 +++-
 2 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch

diff --git a/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch 
b/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch
new file mode 100644
index 000..ca170db00f2
--- /dev/null
+++ b/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch
@@ -0,0 +1,53 @@
+If SGML_CATALOG_FILES is in the environment, pass --catalogs to xmllint and
+xsltproc. Also pass --nonet to xsltproc to detect future missing stylesheet
+problems.
+
+An earlier version of this patch was filed upstream at
+https://github.com/asciidoc/asciidoc-py3/issues/61 so depending on how that 
goes
+this could get merged.
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton 
+
+diff --git a/a2x.py b/a2x.py
+index 2d7699a..582d809 100755
+--- a/a2x.py
 b/a2x.py
+@@ -57,6 +57,10 @@ LYNX_OPTS = '-dump'
+ W3M_OPTS = '-dump -cols 70 -T text/html -no-graph'
+ XSLTPROC_OPTS = ''
+ 
++if "SGML_CATALOG_FILES" in os.environ:
++  XMLLINT += " --catalogs"
++  XSLTPROC += " --catalogs"
++
+ ##
+ # End of configuration file parameters.
+ ##
+@@ -298,7 +302,7 @@ def exec_xsltproc(xsl_file, xml_file, dst_dir, opts = ''):
+ cwd = os.getcwd()
+ shell_cd(dst_dir)
+ try:
+-shell('"%s" %s "%s" "%s"' % (XSLTPROC, opts, xsl_file, xml_file))
++shell('%s %s "%s" "%s"' % (XSLTPROC, opts, xsl_file, xml_file))
+ finally:
+ shell_cd(cwd)
+ 
+@@ -483,7 +487,7 @@ class A2X(AttrDict):
+ self.asciidoc_opts += ' --doctype %s' % self.doctype
+ for attr in self.attributes:
+ self.asciidoc_opts += ' --attribute "%s"' % attr
+-#self.xsltproc_opts += ' --nonet'
++self.xsltproc_opts += ' --nonet'
+ if self.verbose:
+ self.asciidoc_opts += ' --verbose'
+ self.dblatex_opts += ' -V'
+@@ -634,7 +638,7 @@ class A2X(AttrDict):
+ shell('"%s" --backend docbook -a "a2x-format=%s" %s --out-file "%s" 
"%s"' %
+  (self.asciidoc, self.format, self.asciidoc_opts, docbook_file, 
self.asciidoc_file))
+ if not self.no_xmllint and XMLLINT:
+-shell('"%s" --nonet --noout --valid "%s"' % (XMLLINT, 
docbook_file))
++shell('%s --nonet --noout --valid "%s"' % (XMLLINT, docbook_file))
+ 
+ def to_xhtml(self):
+ self.to_docbook()
diff --git a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb 
b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
index d0d15171ac4..f684f12dc72 100644
--- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
+++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
@@ -8,14 +8,19 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 file://COPYRIGHT;md5=029ad5428ba5efa20176b396222d4069"
 
-SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https"
+SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https \
+   file://auto-catalogs.patch"
 SRCREV = "618f6e6f6b558ed1e5f2588cd60a5a6b4f881ca0"
 PV .= "+py3-git${SRCPV}"
 
-DEPENDS = "libxml2-native libxslt-native docbook-xml-dtd4-native"
+DEPENDS = "libxml2-native libxslt-native docbook-xml-dtd4-native 
docbook-xsl-stylesheets-native"
 
 S = "${WORKDIR}/git"
 
+# Tell xmllint where to find the DocBook XML catalogue, because right now it
+# opens /etc/xml/catalog on the host. Depends on auto-catalogs.patch
+export SGML_CATALOG_FILES="file://${STAGING_ETCDIR_NATIVE}/xml/docbook-xml.xml 
file://${STAGING_ETCDIR_NATIVE}/xml/docbook-xsl.xml"
+
 # Not using automake
 inherit autotools-brokensep
 CLEANBROKEN = "1"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] asciidoc: use local docbook XML catalogue

[Burton, Ross]

Retracting this: it then goes and downloads the xsl stylesheets during
do_compile, which is slow and networking during a non-network phase.
Easier hack incoming.

Ross

On Tue, 2 Apr 2019 at 16:25, Ross Burton  wrote:
>
> libxml-native by default uses a XML catalogue at /etc/xml/catalog, instead of
> the one in the sysroot.  Until this is fixed (#13260) override the XML 
> catalogue
> manually in the recipe.
>
> Signed-off-by: Ross Burton 
> ---
>  .../asciidoc/asciidoc/auto-catalogs.patch  | 27 
> ++
>  meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb   |  7 +-
>  2 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch
>
> diff --git a/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch 
> b/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch
> new file mode 100644
> index 000..f507080cd3c
> --- /dev/null
> +++ b/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch
> @@ -0,0 +1,27 @@
> +If SGML_CATALOG_FILES is in the environment, pass --catalogs to xmllint.
> +
> +Upstream-Status: Submitted 
> [https://github.com/asciidoc/asciidoc-py3/issues/61]
> +Signed-off-by: Ross Burton 
> +
> +diff --git a/a2x.py b/a2x.py
> +index 2d7699a..5bb995f 100755
> +--- a/a2x.py
>  b/a2x.py
> +@@ -47,6 +47,8 @@ FOP = 'fop' # pdf generation (--fop 
> option).
> + W3M = 'w3m' # primary text file generator.
> + LYNX = 'lynx'   # alternate text file generator.
> + XMLLINT = 'xmllint' # Set to '' to disable.
> ++if "SGML_CATALOG_FILES" in os.environ:
> ++  XMLLINT += " --catalogs"
> + EPUBCHECK = 'epubcheck' # Set to '' to disable.
> + # External executable default options.
> + ASCIIDOC_OPTS = ''
> +@@ -634,7 +636,7 @@ class A2X(AttrDict):
> + shell('"%s" --backend docbook -a "a2x-format=%s" %s --out-file "%s" 
> "%s"' %
> +  (self.asciidoc, self.format, self.asciidoc_opts, docbook_file, 
> self.asciidoc_file))
> + if not self.no_xmllint and XMLLINT:
> +-shell('"%s" --nonet --noout --valid "%s"' % (XMLLINT, 
> docbook_file))
> ++shell('%s --nonet --noout --valid "%s"' % (XMLLINT, 
> docbook_file))
> +
> + def to_xhtml(self):
> + self.to_docbook()
> diff --git a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb 
> b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
> index d0d15171ac4..88ee93bfc10 100644
> --- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
> +++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
> @@ -8,7 +8,8 @@ LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
>  file://COPYRIGHT;md5=029ad5428ba5efa20176b396222d4069"
>
> -SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https"
> +SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https \
> +   file://auto-catalogs.patch"
>  SRCREV = "618f6e6f6b558ed1e5f2588cd60a5a6b4f881ca0"
>  PV .= "+py3-git${SRCPV}"
>
> @@ -16,6 +17,10 @@ DEPENDS = "libxml2-native libxslt-native 
> docbook-xml-dtd4-native"
>
>  S = "${WORKDIR}/git"
>
> +# Tell xmllint where to find the DocBook XML catalogue, because right now it
> +# opens /etc/xml/catalog on the host. Depends on auto-catalogs.patch
> +export 
> SGML_CATALOG_FILES="file://${STAGING_ETCDIR_NATIVE}/xml/docbook-xml.xml"
> +
>  # Not using automake
>  inherit autotools-brokensep
>  CLEANBROKEN = "1"
> --
> 2.11.0
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] tzdata: Install everything by default

[Paul Barker]

On Tue, 2 Apr 2019, at 17:29, Mark Hatle wrote:
> On 4/2/19 9:15 AM, Paul Barker wrote:
> > tzdata is converted to an empty meta package which pulls in all
> > subpackages. The subpackages are defined in a TZ_PACKAGES variable so
> > that we don't have to repeat ourselves.
> > 
> > The timezones and conffiles which were in the tzdata package are moved
> > to a new 'tzdata-core' package.
> 
> Is there any type of 'RREPLACES' or anything that should be added so previous
> users of tzdata-all get tzdata in a package upgrade?

tzdata-all is just what I called it in my first attempt at this patch. So there 
was never a tzdata-all upstream to my knowledge.

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] tzdata: Install everything by default

[Martin Jansa]

RPROVIDES/RREPLACES/RCONFLICTS is the right combo (you need all 3 for opkg
to remove the old package IIRC).

On Tue, Apr 2, 2019 at 6:29 PM Mark Hatle  wrote:

> On 4/2/19 9:15 AM, Paul Barker wrote:
> > tzdata is converted to an empty meta package which pulls in all
> > subpackages. The subpackages are defined in a TZ_PACKAGES variable so
> > that we don't have to repeat ourselves.
> >
> > The timezones and conffiles which were in the tzdata package are moved
> > to a new 'tzdata-core' package.
>
> Is there any type of 'RREPLACES' or anything that should be added so
> previous
> users of tzdata-all get tzdata in a package upgrade?
>
> (or is it ROBSOLETES, or..  I can never remember..)
>
> --Mark
>
> > Signed-off-by: Paul Barker 
> > ---
> >  meta/recipes-extended/timezone/tzdata.bb | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/meta/recipes-extended/timezone/tzdata.bb
> b/meta/recipes-extended/timezone/tzdata.bb
> > index 7542ce52d2..82fe369baa 100644
> > --- a/meta/recipes-extended/timezone/tzdata.bb
> > +++ b/meta/recipes-extended/timezone/tzdata.bb
> > @@ -80,9 +80,11 @@ pkg_postinst_${PN} () {
> >  # Packages primarily organized by directory with a major city
> >  # in most time zones in the base package
> >
> > -PACKAGES = "tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
> > +TZ_PACKAGES = " \
> > +tzdata-core tzdata-misc tzdata-posix tzdata-right tzdata-africa \
> >  tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
> >  tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific"
> > +PACKAGES = "${TZ_PACKAGES} ${PN}"
> >
> >  FILES_tzdata-africa += "${datadir}/zoneinfo/Africa/*"
> >  RPROVIDES_tzdata-africa = "tzdata-africa"
> > @@ -124,7 +126,6 @@ RPROVIDES_tzdata-posix = "tzdata-posix"
> >  FILES_tzdata-right += "${datadir}/zoneinfo/right/*"
> >  RPROVIDES_tzdata-right = "tzdata-right"
> >
> > -
> >  FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba   \
> >  ${datadir}/zoneinfo/Egypt\
> >  ${datadir}/zoneinfo/Eire \
> > @@ -145,8 +146,8 @@ FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba
>  \
> >  ${datadir}/zoneinfo/Turkey"
> >  RPROVIDES_tzdata-misc = "tzdata-misc"
> >
> > -
> > -FILES_${PN} += "${datadir}/zoneinfo/Pacific/Honolulu \
> > +FILES_tzdata-core += " \
> > +${datadir}/zoneinfo/Pacific/Honolulu \
> >  ${datadir}/zoneinfo/America/Anchorage\
> >  ${datadir}/zoneinfo/America/Los_Angeles  \
> >  ${datadir}/zoneinfo/America/Denver   \
> > @@ -201,5 +202,8 @@ FILES_${PN} +=
> "${datadir}/zoneinfo/Pacific/Honolulu \
> >  ${datadir}/zoneinfo/iso3166.tab  \
> >  ${datadir}/zoneinfo/Etc/*"
> >
> > -CONFFILES_${PN} += "${@ "${sysconfdir}/timezone" if
> bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
> > -CONFFILES_${PN} += "${sysconfdir}/localtime"
> > +CONFFILES_tzdata-core += "${@ "${sysconfdir}/timezone" if
> bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
> > +CONFFILES_tzdata-core += "${sysconfdir}/localtime"
> > +
> > +ALLOW_EMPTY_${PN} = "1"
> > +RDEPENDS_${PN} = "${TZ_PACKAGES}"
> >
>
> --
> ___
> 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] tzdata: Install everything by default

[Mark Hatle]

On 4/2/19 9:15 AM, Paul Barker wrote:
> tzdata is converted to an empty meta package which pulls in all
> subpackages. The subpackages are defined in a TZ_PACKAGES variable so
> that we don't have to repeat ourselves.
> 
> The timezones and conffiles which were in the tzdata package are moved
> to a new 'tzdata-core' package.

Is there any type of 'RREPLACES' or anything that should be added so previous
users of tzdata-all get tzdata in a package upgrade?

(or is it ROBSOLETES, or..  I can never remember..)

--Mark

> Signed-off-by: Paul Barker 
> ---
>  meta/recipes-extended/timezone/tzdata.bb | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/recipes-extended/timezone/tzdata.bb 
> b/meta/recipes-extended/timezone/tzdata.bb
> index 7542ce52d2..82fe369baa 100644
> --- a/meta/recipes-extended/timezone/tzdata.bb
> +++ b/meta/recipes-extended/timezone/tzdata.bb
> @@ -80,9 +80,11 @@ pkg_postinst_${PN} () {
>  # Packages primarily organized by directory with a major city
>  # in most time zones in the base package
>  
> -PACKAGES = "tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
> +TZ_PACKAGES = " \
> +tzdata-core tzdata-misc tzdata-posix tzdata-right tzdata-africa \
>  tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
>  tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific"
> +PACKAGES = "${TZ_PACKAGES} ${PN}"
>  
>  FILES_tzdata-africa += "${datadir}/zoneinfo/Africa/*"
>  RPROVIDES_tzdata-africa = "tzdata-africa"
> @@ -124,7 +126,6 @@ RPROVIDES_tzdata-posix = "tzdata-posix"
>  FILES_tzdata-right += "${datadir}/zoneinfo/right/*"
>  RPROVIDES_tzdata-right = "tzdata-right"
>  
> -
>  FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba   \
>  ${datadir}/zoneinfo/Egypt\
>  ${datadir}/zoneinfo/Eire \
> @@ -145,8 +146,8 @@ FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba   \
>  ${datadir}/zoneinfo/Turkey"
>  RPROVIDES_tzdata-misc = "tzdata-misc"
>  
> -
> -FILES_${PN} += "${datadir}/zoneinfo/Pacific/Honolulu \
> +FILES_tzdata-core += " \
> +${datadir}/zoneinfo/Pacific/Honolulu \
>  ${datadir}/zoneinfo/America/Anchorage\
>  ${datadir}/zoneinfo/America/Los_Angeles  \
>  ${datadir}/zoneinfo/America/Denver   \
> @@ -201,5 +202,8 @@ FILES_${PN} += "${datadir}/zoneinfo/Pacific/Honolulu \
>  ${datadir}/zoneinfo/iso3166.tab  \
>  ${datadir}/zoneinfo/Etc/*"
>  
> -CONFFILES_${PN} += "${@ "${sysconfdir}/timezone" if 
> bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
> -CONFFILES_${PN} += "${sysconfdir}/localtime"
> +CONFFILES_tzdata-core += "${@ "${sysconfdir}/timezone" if 
> bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
> +CONFFILES_tzdata-core += "${sysconfdir}/localtime"
> +
> +ALLOW_EMPTY_${PN} = "1"
> +RDEPENDS_${PN} = "${TZ_PACKAGES}"
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Link issue of virglrenderer on x86 with gcc options '-O2 -fvisibility=default'

[Khem Raj]

On Tue, Apr 2, 2019 at 8:46 AM Kang Kai  wrote:
>
> Hi Raj,
>
> I meet a link problem of virglrenderer with gcc options '-O2
> -fvisibility=default' configured in local.conf:
>
> SELECTED_OPTIMIZATION = "-O2 -fvisibility=default"
>
> It fails on qemux86 but succeeds on x86-64.
>
> And the error message:
>
> | i586-poky-linux-libtool: link: i586-poky-linux-gcc  -m32 -march=i586
> -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
> -Werror=
> format-security
> --sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot
> -shared  -fPIC -DPIC
>   .libs/virglrenderer.o  *-Wl,--whole-archive* ./.libs/libvrend.a
> gallium/auxiliary/.libs/libgallium.a *-Wl,--no-whole-archive*  -lm -ldrm
> -lgbm -lepoxy -lX1
> 1  -m32 -march=i586 -fstack-protector-strong
> --sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-
> sysroot -O2 -Wl,-Bsymbolic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
> -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread
> -Wl,-soname
> -Wl,libvirglrenderer.so.0 -o .libs/libvirglrenderer.so.0.2.0
> |
> /home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/../../libexec/
> i586-poky-linux/gcc/i586-poky-linux/8.3.0/ld:
> gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
> R_386_GOTOFF against undefined symbol `ut
> il_cpu_caps' can not be used when making a shared object
>
> It could pass if options -Wl,--whole-archive and -Wl,--no-whole-archive
> are removed.
>
> It says 'relocation R_386_GOTOFF' but when I check the file, it shows
> relocation type is R_386_GOT32X:
>
> $ readelf --relocs ./util/.libs/u_cpu_detect.o | grep util_cpu_caps
> 0092  102b R_386_GOT32X  0004   util_cpu_caps
>
> AFAIK R_386_GOT32X is not used with PIC. But I don't know why the type
> is R_386_GOT32X that -fPIC has been applied already?
>
> Any suggestion is great appreciated. Thanks.
>

it seems you have to build PIC archive for libgallium.a, it might not
be using the right -fPIC flags during compile/link phase.

>
> --
> Kai Kang
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Link issue of virglrenderer on x86 with gcc options '-O2 -fvisibility=default'

[Kang Kai]

Hi Raj,

I meet a link problem of virglrenderer with gcc options '-O2 
-fvisibility=default' configured in local.conf:


SELECTED_OPTIMIZATION = "-O2 -fvisibility=default"

It fails on qemux86 but succeeds on x86-64.

And the error message:

| i586-poky-linux-libtool: link: i586-poky-linux-gcc  -m32 -march=i586 
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
-Werror=
format-security 
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot 
-shared  -fPIC -DPIC
 .libs/virglrenderer.o  *-Wl,--whole-archive* ./.libs/libvrend.a 
gallium/auxiliary/.libs/libgallium.a *-Wl,--no-whole-archive*  -lm -ldrm 
-lgbm -lepoxy -lX1
1  -m32 -march=i586 -fstack-protector-strong 
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-
sysroot -O2 -Wl,-Bsymbolic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread 
-Wl,-soname

-Wl,libvirglrenderer.so.0 -o .libs/libvirglrenderer.so.0.2.0
| 
/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/../../libexec/
i586-poky-linux/gcc/i586-poky-linux/8.3.0/ld: 
gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation 
R_386_GOTOFF against undefined symbol `ut

il_cpu_caps' can not be used when making a shared object

It could pass if options -Wl,--whole-archive and -Wl,--no-whole-archive 
are removed.


It says 'relocation R_386_GOTOFF' but when I check the file, it shows 
relocation type is R_386_GOT32X:


$ readelf --relocs ./util/.libs/u_cpu_detect.o | grep util_cpu_caps
0092  102b R_386_GOT32X  0004   util_cpu_caps

AFAIK R_386_GOT32X is not used with PIC. But I don't know why the type 
is R_386_GOT32X that -fPIC has been applied already?


Any suggestion is great appreciated. Thanks.


--
Kai Kang

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] asciidoc: use local docbook XML catalogue

[Ross Burton]

libxml-native by default uses a XML catalogue at /etc/xml/catalog, instead of
the one in the sysroot.  Until this is fixed (#13260) override the XML catalogue
manually in the recipe.

Signed-off-by: Ross Burton 
---
 .../asciidoc/asciidoc/auto-catalogs.patch  | 27 ++
 meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb   |  7 +-
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch

diff --git a/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch 
b/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch
new file mode 100644
index 000..f507080cd3c
--- /dev/null
+++ b/meta/recipes-extended/asciidoc/asciidoc/auto-catalogs.patch
@@ -0,0 +1,27 @@
+If SGML_CATALOG_FILES is in the environment, pass --catalogs to xmllint.
+
+Upstream-Status: Submitted [https://github.com/asciidoc/asciidoc-py3/issues/61]
+Signed-off-by: Ross Burton 
+
+diff --git a/a2x.py b/a2x.py
+index 2d7699a..5bb995f 100755
+--- a/a2x.py
 b/a2x.py
+@@ -47,6 +47,8 @@ FOP = 'fop' # pdf generation (--fop option).
+ W3M = 'w3m' # primary text file generator.
+ LYNX = 'lynx'   # alternate text file generator.
+ XMLLINT = 'xmllint' # Set to '' to disable.
++if "SGML_CATALOG_FILES" in os.environ:
++  XMLLINT += " --catalogs"
+ EPUBCHECK = 'epubcheck' # Set to '' to disable.
+ # External executable default options.
+ ASCIIDOC_OPTS = ''
+@@ -634,7 +636,7 @@ class A2X(AttrDict):
+ shell('"%s" --backend docbook -a "a2x-format=%s" %s --out-file "%s" 
"%s"' %
+  (self.asciidoc, self.format, self.asciidoc_opts, docbook_file, 
self.asciidoc_file))
+ if not self.no_xmllint and XMLLINT:
+-shell('"%s" --nonet --noout --valid "%s"' % (XMLLINT, 
docbook_file))
++shell('%s --nonet --noout --valid "%s"' % (XMLLINT, docbook_file))
+ 
+ def to_xhtml(self):
+ self.to_docbook()
diff --git a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb 
b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
index d0d15171ac4..88ee93bfc10 100644
--- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
+++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
@@ -8,7 +8,8 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 file://COPYRIGHT;md5=029ad5428ba5efa20176b396222d4069"
 
-SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https"
+SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https \
+   file://auto-catalogs.patch"
 SRCREV = "618f6e6f6b558ed1e5f2588cd60a5a6b4f881ca0"
 PV .= "+py3-git${SRCPV}"
 
@@ -16,6 +17,10 @@ DEPENDS = "libxml2-native libxslt-native 
docbook-xml-dtd4-native"
 
 S = "${WORKDIR}/git"
 
+# Tell xmllint where to find the DocBook XML catalogue, because right now it
+# opens /etc/xml/catalog on the host. Depends on auto-catalogs.patch
+export SGML_CATALOG_FILES="file://${STAGING_ETCDIR_NATIVE}/xml/docbook-xml.xml"
+
 # Not using automake
 inherit autotools-brokensep
 CLEANBROKEN = "1"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Status WW14'19

[sjolley.yp.pm]

Current Dev Position: YP 2.7 M4 (New feature Freeze has begun.)

Next Deadline: YP 2.7 M3 Release Target was Mar. 8, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Ross
*   SWAT team rotation: Ross -> Amanda on Apr. 5, 2019
*   SWAT team rotation: Amanda -> Chen on Apr. 12, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   YP 2.8 Planning meeting Tuesday April 2nd at 8am PDT (
 https://zoom.us/j/990892712) or see the invite
on the mailing list at: (

https://lists.yoctoproject.org/pipermail/yocto/2019-April/044654.html) 
*   Bug Triage meeting Thursday April 4th at 7:30am PDT (
 https://zoom.us/j/454367603)

 

Key Status/Updates:

*   The QA report for M3 rc1 is available. This is the first time we've
used the new QA process so we're still understanding how the new format for
the data works out. There are some issues but right now we believe we'll aim
to fix these before the final release build and proceed to that with the
first build of M4 aiming for next week.
*   The YP 2.7 M3 rc1 report is summarized at

https://lists.yoctoproject.org/pipermail/yocto/2019-April/044667.html and
the results are at

https://autobuilder.yocto.io/pub/releases/yocto-2.7_M3.rc1/testresults/.
*   2.5.3 and 2.6.2 stable releases were built and submitted to QA last
week.
*   The "warrior" branches for 2.7 have been created and the metadata
updated. This will have a ripple effect across the layers as they update to
match this. This process is important as it allows layers to indicate which
versions of the project they are compatible with.
*   The 2.8 planning discussions are starting and there is a google doc
summarising the discussions so far:

https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJG
XbU/

If people are planning to work on specific things in 2.8 please let us know
so we can incorporate this into our plans. If you're interested in working
on anything in the document, please also let us know or talk with us in one
of the planning meetings.

 

Planned Releases for YP 2.7:

*   YP 2.7 M4 Cutoff is Apr. 1, 2019
*   YP 2.7 M4 Release Target is Apr. 26, 2019

 

Planned upcoming dot releases:

*   YP 2.5.3 (Sumo) is in QA.
*   YP 2.6.2 (Thud) is in QA.

 

Tracking Metrics:

*   WDD 2442 (last week 2418) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1542 (last week 1538)
*   Patches in the Pending State: 654 (42%) [last week 656 (43%)]

 

Key Status Links for YP:

 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:   
sjolley.yp...@gmail.com

 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] tzdata: Install everything by default

[Paul Barker]

tzdata is converted to an empty meta package which pulls in all
subpackages. The subpackages are defined in a TZ_PACKAGES variable so
that we don't have to repeat ourselves.

The timezones and conffiles which were in the tzdata package are moved
to a new 'tzdata-core' package.

Signed-off-by: Paul Barker 
---
 meta/recipes-extended/timezone/tzdata.bb | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index 7542ce52d2..82fe369baa 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -80,9 +80,11 @@ pkg_postinst_${PN} () {
 # Packages primarily organized by directory with a major city
 # in most time zones in the base package
 
-PACKAGES = "tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
+TZ_PACKAGES = " \
+tzdata-core tzdata-misc tzdata-posix tzdata-right tzdata-africa \
 tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
 tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific"
+PACKAGES = "${TZ_PACKAGES} ${PN}"
 
 FILES_tzdata-africa += "${datadir}/zoneinfo/Africa/*"
 RPROVIDES_tzdata-africa = "tzdata-africa"
@@ -124,7 +126,6 @@ RPROVIDES_tzdata-posix = "tzdata-posix"
 FILES_tzdata-right += "${datadir}/zoneinfo/right/*"
 RPROVIDES_tzdata-right = "tzdata-right"
 
-
 FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba   \
 ${datadir}/zoneinfo/Egypt\
 ${datadir}/zoneinfo/Eire \
@@ -145,8 +146,8 @@ FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba   \
 ${datadir}/zoneinfo/Turkey"
 RPROVIDES_tzdata-misc = "tzdata-misc"
 
-
-FILES_${PN} += "${datadir}/zoneinfo/Pacific/Honolulu \
+FILES_tzdata-core += " \
+${datadir}/zoneinfo/Pacific/Honolulu \
 ${datadir}/zoneinfo/America/Anchorage\
 ${datadir}/zoneinfo/America/Los_Angeles  \
 ${datadir}/zoneinfo/America/Denver   \
@@ -201,5 +202,8 @@ FILES_${PN} += "${datadir}/zoneinfo/Pacific/Honolulu \
 ${datadir}/zoneinfo/iso3166.tab  \
 ${datadir}/zoneinfo/Etc/*"
 
-CONFFILES_${PN} += "${@ "${sysconfdir}/timezone" if 
bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
-CONFFILES_${PN} += "${sysconfdir}/localtime"
+CONFFILES_tzdata-core += "${@ "${sysconfdir}/timezone" if 
bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
+CONFFILES_tzdata-core += "${sysconfdir}/localtime"
+
+ALLOW_EMPTY_${PN} = "1"
+RDEPENDS_${PN} = "${TZ_PACKAGES}"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] tzdata: Install everything by default

[Paul Barker]

This is a v2 of "tzdata: Add tzdata-all package" with a slightly different
approach.

I've took onboard what Ross said and now the "install everthing" package is
simply "tzdata" not "tzdata-all". A new "tzdata-core" package is created for
what used to be in "tzdata" itself.

Paul Barker (1):
  tzdata: Install everything by default

 meta/recipes-extended/timezone/tzdata.bb | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized

[Adrian Bunk]

On Tue, Apr 02, 2019 at 05:08:33PM +0800, changqing...@windriver.com wrote:
> From: Changqing Li 
> 
> fix below compile error with -Werror=maybe-uninitialized
> 
> | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error: 
> 'gltype' may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
> |  *out_gltype = gltype;
> |  ^~~~
> | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error: 
> 'glintformat' may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
> |  *out_glintformat = glintformat;
> |  ~^
>...

Looking at the code, is this a failure that only happens with DEBUG_FLAGS?
 
> +--- a/cogl/driver/gl/gles/cogl-driver-gles.c
>  b/cogl/driver/gl/gles/cogl-driver-gles.c
> +@@ -74,9 +74,9 @@ _cogl_driver_pixel_format_to_gl (CoglContext *context,
> +  GLenum *out_gltype)
> + {
> +   CoglPixelFormat required_format;
> +-  GLenum glintformat;
> ++  GLenum glintformat = 0;
> +   GLenum glformat = 0;
> +-  GLenum gltype;
> ++  GLenum gltype = 0;
>...

Assigning random values to variables is a bug,
they do not even seem to be valid values for these variables.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glib-networking: remove PACKAGECONFIG for gnutls

[Burton, Ross]

On Tue, 2 Apr 2019 at 10:44, Andreas Müller  wrote:
> Since I don't see that meson configuration warnings make it into
> warrier: Wouldn't it be better to update the glib recipes to 2.60 on
> master to avoid back and forth?

Seems sensible.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glib-networking: remove PACKAGECONFIG for gnutls

[Andreas Müller]

On Tue, Apr 2, 2019 at 9:35 AM Alexander Kanavin  wrote:
>
> This option was re-instated in 2.60, can you add a comment to the recipe 
> please? So that when it’s upgraded, gnutls is again optional.
>
> Alex
>
Since I don't see that meson configuration warnings make it into
warrier: Wouldn't it be better to update the glib recipes to 2.60 on
master to avoid back and forth?

Andreas
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized

[changqing.li]

From: Changqing Li 

fix below compile error with -Werror=maybe-uninitialized

| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error: 
'gltype' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|  *out_gltype = gltype;
|  ^~~~
| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error: 
'glintformat' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|  *out_glintformat = glintformat;
|  ~^

Signed-off-by: Changqing Li 
---
 ...mpile-error-with-Werror-maybe-uninitializ.patch | 40 ++
 meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb  |  4 ++-
 2 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-graphics/cogl/cogl-1.0/0001-cogl-fix-compile-error-with-Werror-maybe-uninitializ.patch

diff --git 
a/meta/recipes-graphics/cogl/cogl-1.0/0001-cogl-fix-compile-error-with-Werror-maybe-uninitializ.patch
 
b/meta/recipes-graphics/cogl/cogl-1.0/0001-cogl-fix-compile-error-with-Werror-maybe-uninitializ.patch
new file mode 100644
index 000..3c99d25
--- /dev/null
+++ 
b/meta/recipes-graphics/cogl/cogl-1.0/0001-cogl-fix-compile-error-with-Werror-maybe-uninitializ.patch
@@ -0,0 +1,40 @@
+From e05ee89fcc978fceccab3e4724a3a37f7a338499 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Tue, 2 Apr 2019 14:48:49 +0800
+Subject: [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized
+
+fix below compile error with -Werror=maybe-uninitialized
+
+| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error: 
'gltype' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
+|  *out_gltype = gltype;
+|  ^~~~
+| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error: 
'glintformat' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
+|  *out_glintformat = glintformat;
+|  ~^
+
+Upstream-Status: Submitted 
[https://github.com/GNOME/cogl/pull/4/commits/be7a7b983952d3f2ce2cbaa7b89f413b92e15066]
+
+Signed-off-by: Changqing Li 
+---
+ cogl/driver/gl/gles/cogl-driver-gles.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/cogl/driver/gl/gles/cogl-driver-gles.c 
b/cogl/driver/gl/gles/cogl-driver-gles.c
+index e94449f..a59d815 100644
+--- a/cogl/driver/gl/gles/cogl-driver-gles.c
 b/cogl/driver/gl/gles/cogl-driver-gles.c
+@@ -74,9 +74,9 @@ _cogl_driver_pixel_format_to_gl (CoglContext *context,
+  GLenum *out_gltype)
+ {
+   CoglPixelFormat required_format;
+-  GLenum glintformat;
++  GLenum glintformat = 0;
+   GLenum glformat = 0;
+-  GLenum gltype;
++  GLenum gltype = 0;
+ 
+   required_format = format;
+ 
+-- 
+2.7.4
+
diff --git a/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb 
b/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb
index 5901062..5ddeb4a 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb
+++ b/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb
@@ -1,7 +1,9 @@
 require cogl-1.0.inc
 
 SRC_URI += "file://test-backface-culling.c-fix-may-be-used-uninitialize.patch \
-file://0001-Fix-an-incorrect-preprocessor-conditional.patch"
+file://0001-Fix-an-incorrect-preprocessor-conditional.patch \
+
file://0001-cogl-fix-compile-error-with-Werror-maybe-uninitializ.patch \
+   "
 SRC_URI[archive.md5sum] = "d53b708ca7c4af03d7254e46945d6b33"
 SRC_URI[archive.sha256sum] = 
"39a718cdb64ea45225a7e94f88dddec1869ab37a21b339ad058a9d898782c00d"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] avahi: fix CVE-2017-6519

[Burton, Ross]

On Tue, 2 Apr 2019 at 08:49, Kang Kai  wrote:
> I have checked CVE-2018-1000845 which is rejected that it is duplicate
> of CVE-2017-6519. That why didn't list CVE-2018-1000845 in patch and
> commit message.

Okay it's actually been rejected, so tooling shouldn't be seeing it.

Thanks,
Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] fatresize_1.0.2.bb: Add recipe for fatresize command line tool

[Nathan Rossi]

On Tue, 2 Apr 2019 at 18:40, Alexander Kanavin  wrote:
>
> Should this go to meta-oe though? It doesn’t seem like an essential tool.

My thinking was to suggest it in oe-core given its relation to parted.
However if it would be better placed in meta-oe/meta-filesystems I can
update this patch and resubmit it there?

Thanks,
Nathan

>
> Alex
>
> > On 2 Apr 2019, at 10.23, Nathan Rossi  wrote:
> >
> > The fatresize command line tool provides command line access to the
> > libparted-fs-resize library implementation of the FAT partition
> > resizing.
> >
> > This tool is useful for safely resizing FAT partitions which are
> > commonly found as the boot partition on a variety of SoC targets (e.g.
> > RaspberryPi).
> >
> > The Debian version of the source is used as the original upstream on
> > SourceForge is no longer actively maintained.
> >
> > Signed-off-by: Nathan Rossi 
> > ---
> > The reason for locating the recipe in the parted directory is that the
> > program itself does not implement the FAT partition resizing it is
> > merely exposing the functionality from libparted-fs-resize as a command
> > line tool.
> > ---
> > meta/recipes-extended/parted/fatresize_1.0.2.bb | 15 +++
> > 1 file changed, 15 insertions(+)
> > create mode 100644 meta/recipes-extended/parted/fatresize_1.0.2.bb
> >
> > diff --git a/meta/recipes-extended/parted/fatresize_1.0.2.bb 
> > b/meta/recipes-extended/parted/fatresize_1.0.2.bb
> > new file mode 100644
> > index 00..a2f6b6d131
> > --- /dev/null
> > +++ b/meta/recipes-extended/parted/fatresize_1.0.2.bb
> > @@ -0,0 +1,15 @@
> > +SUMMARY = "Resize FAT partitions using libparted"
> > +SECTION = "console/tools"
> > +LICENSE = "GPLv2"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
> > +
> > +SRC_URI = "git://salsa.debian.org/parted-team/fatresize.git;protocol=https"
> > +SRCREV = "3f80afc76ad82d4a1b852a6c8dea24cd9f5e7a24"
> > +
> > +PV = "1.0.2-11-git+${SRCPV}"
> > +
> > +S = "${WORKDIR}/git"
> > +
> > +DEPENDS = "parted"
> > +
> > +inherit autotools pkgconfig
> > ---
> > 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] quote: update to 4.05

[Paul Barker]

On 31/03/2019 17:17, Oleksandr Kravchuk wrote:

License checksum from quota.c was removed since according to the
project, copyrighted code in question has been replaced with own
implementation (see @bcbc0d08e5cd).

Removed patch has been upstreamed.

Signed-off-by: Oleksandr Kravchuk 
---
  .../quota/quota/remove_non_posix_types.patch  | 198 --
  .../quota/{quota_4.04.bb => quota_4.05.bb}|   8 +-
  2 files changed, 3 insertions(+), 203 deletions(-)
  delete mode 100644 
meta/recipes-extended/quota/quota/remove_non_posix_types.patch
  rename meta/recipes-extended/quota/{quota_4.04.bb => quota_4.05.bb} (80%)

diff --git a/meta/recipes-extended/quota/quota/remove_non_posix_types.patch 
b/meta/recipes-extended/quota/quota/remove_non_posix_types.patch
deleted file mode 100644
index 06ff13cb98..00
--- a/meta/recipes-extended/quota/quota/remove_non_posix_types.patch
+++ /dev/null
@@ -1,198 +0,0 @@
-Use proper C99 integer types
-
-Upstream-Status: Pending
-
-Signed-off-by: Khem Raj 
-
-Index: quota-tools/bylabel.c
-===
 quota-tools.orig/bylabel.c
-+++ quota-tools/bylabel.c
-@@ -20,6 +20,7 @@
- #include 
- #include 
- #include 
-+#include 
-
- #include "bylabel.h"
- #include "common.h"
-@@ -37,32 +38,32 @@ static struct uuidCache_s {
-
- #define EXT2_SUPER_MAGIC  0xEF53
- struct ext2_super_block {
--  u_char s_dummy1[56];
--  u_char s_magic[2];
--  u_char s_dummy2[46];
--  u_char s_uuid[16];
--  u_char s_volume_name[16];
-+  uint8_t s_dummy1[56];
-+  uint8_t s_magic[2];
-+  uint8_t s_dummy2[46];
-+  uint8_t s_uuid[16];
-+  uint8_t s_volume_name[16];
- };
-
--#define ext2magic(s)  ((uint) s.s_magic[0] + (((uint) s.s_magic[1]) << 8))
-+#define ext2magic(s)  ((uint32_t) s.s_magic[0] + (((uint32_t) s.s_magic[1]) 
<< 8))
-
- #define XFS_SUPER_MAGIC "XFSB"
- #define XFS_SUPER_MAGIC2 "BSFX"
- struct xfs_super_block {
--  u_char s_magic[4];
--  u_char s_dummy[28];
--  u_char s_uuid[16];
--  u_char s_dummy2[60];
--  u_char s_fsname[12];
-+  uint8_t s_magic[4];
-+  uint8_t s_dummy[28];
-+  uint8_t s_uuid[16];
-+  uint8_t s_dummy2[60];
-+  uint8_t s_fsname[12];
- };
-
- #define REISER_SUPER_MAGIC"ReIsEr2Fs"
- struct reiserfs_super_block {
--  u_char s_dummy1[52];
--  u_char s_magic[10];
--  u_char s_dummy2[22];
--  u_char s_uuid[16];
--  u_char s_volume_name[16];
-+  uint8_t s_dummy1[52];
-+  uint8_t s_magic[10];
-+  uint8_t s_dummy2[22];
-+  uint8_t s_uuid[16];
-+  uint8_t s_volume_name[16];
- };
-
- static inline unsigned short swapped(unsigned short a)
-@@ -222,7 +223,7 @@ static char *get_spec_by_x(int n, const
-   return NULL;
- }
-
--static u_char fromhex(char c)
-+static uint8_t fromhex(char c)
- {
-   if (isdigit(c))
-   return (c - '0');
-@@ -234,7 +235,7 @@ static u_char fromhex(char c)
-
- static char *get_spec_by_uuid(const char *s)
- {
--  u_char uuid[16];
-+  uint8_t uuid[16];
-   int i;
-
-   if (strlen(s) != 36 || s[8] != '-' || s[13] != '-' || s[18] != '-' || 
s[23] != '-')
-Index: quota-tools/quot.c
-===
 quota-tools.orig/quot.c
-+++ quota-tools/quot.c
-@@ -47,6 +47,7 @@
- #include 
- #include 
- #include 
-+#include 
-
- #include "pot.h"
- #include "quot.h"
-@@ -56,8 +57,8 @@
- #include "quotasys.h"
-
- #define   TSIZE   500
--static __uint64_t sizes[TSIZE];
--static __uint64_t overflow;
-+static uint64_t sizes[TSIZE];
-+static uint64_t overflow;
-
- static int aflag;
- static int cflag;
-@@ -72,7 +73,7 @@ static time_t now;
- char *progname;
-
- static void mounttable(void);
--static char *idname(__uint32_t, int);
-+static char *idname(uint32_t, int);
- static void report(const char *, const char *, int);
- static void creport(const char *, const char *);
-
-@@ -173,7 +174,7 @@ static int qcmp(du_t * p1, du_t * p2)
- static void creport(const char *file, const char *fsdir)
- {
-   int i;
--  __uint64_t t = 0;
-+  uint64_t t = 0;
-
-   printf(_("%s (%s):\n"), file, fsdir);
-   for (i = 0; i < TSIZE - 1; i++)
-@@ -219,7 +220,7 @@ static void report(const char *file, con
-   }
- }
-
--static idcache_t *getnextent(int type, __uint32_t id, int byid)
-+static idcache_t *getnextent(int type, uint32_t id, int byid)
- {
-   struct passwd *pw;
-   struct group  *gr;
-@@ -240,7 +241,7 @@ static idcache_t *getnextent(int type, _
-   return 
- }
-
--static char *idname(__uint32_t id, int type)
-+static char *idname(uint32_t id, int type)
- {
-   idcache_t *ncp, *idp;
-   static idcache_t nc[2][NID];
-@@ -286,8 +287,8 @@ static void acctXFS(xfs_bstat_t *p)
- {
-   register du_t *dp;
-   du_t **hp;
--  __uint64_t size;
--  __uint32_t i, id;
-+  uint64_t size;
-+  uint32_t i, id;
-
-   if ((p->bs_mode & S_IFMT) == 0)
-  

Re: [OE-core] [PATCH] fatresize_1.0.2.bb: Add recipe for fatresize command line tool

[Alexander Kanavin]

Should this go to meta-oe though? It doesn’t seem like an essential tool.

Alex

> On 2 Apr 2019, at 10.23, Nathan Rossi  wrote:
> 
> The fatresize command line tool provides command line access to the
> libparted-fs-resize library implementation of the FAT partition
> resizing.
> 
> This tool is useful for safely resizing FAT partitions which are
> commonly found as the boot partition on a variety of SoC targets (e.g.
> RaspberryPi).
> 
> The Debian version of the source is used as the original upstream on
> SourceForge is no longer actively maintained.
> 
> Signed-off-by: Nathan Rossi 
> ---
> The reason for locating the recipe in the parted directory is that the
> program itself does not implement the FAT partition resizing it is
> merely exposing the functionality from libparted-fs-resize as a command
> line tool.
> ---
> meta/recipes-extended/parted/fatresize_1.0.2.bb | 15 +++
> 1 file changed, 15 insertions(+)
> create mode 100644 meta/recipes-extended/parted/fatresize_1.0.2.bb
> 
> diff --git a/meta/recipes-extended/parted/fatresize_1.0.2.bb 
> b/meta/recipes-extended/parted/fatresize_1.0.2.bb
> new file mode 100644
> index 00..a2f6b6d131
> --- /dev/null
> +++ b/meta/recipes-extended/parted/fatresize_1.0.2.bb
> @@ -0,0 +1,15 @@
> +SUMMARY = "Resize FAT partitions using libparted"
> +SECTION = "console/tools"
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
> +
> +SRC_URI = "git://salsa.debian.org/parted-team/fatresize.git;protocol=https"
> +SRCREV = "3f80afc76ad82d4a1b852a6c8dea24cd9f5e7a24"
> +
> +PV = "1.0.2-11-git+${SRCPV}"
> +
> +S = "${WORKDIR}/git"
> +
> +DEPENDS = "parted"
> +
> +inherit autotools pkgconfig
> ---
> 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] [oe-core][THUD][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk

[Jaewon Lee]

Disregard, will send on master branch

Thanks,
Jaewon

-Original Message-
From: Jaewon Lee  
Sent: Monday, April 1, 2019 4:58 PM
To: openembedded-core@lists.openembedded.org; Alejandro Enedino Hernandez 
Samaniego ; Manjukumar Harthikote Matha 
; Bruce Ashfield 
Cc: Jaewon Lee 
Subject: [oe-core][THUD][PATCH] Introduce mechanism to keep nativesdk* sstate 
in esdk

Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all nativesdk* sstate 
into esdk Currently locked-sigs.inc is generated during do_sdk_depends which 
doesn't pull in nativesdk packages. Generating another locked-sigs.inc in 
do_populate_sdk_ext and pruning it to only nativesdk* packages by using a 
modified version of the already existing function prune_locked_sigs and merging 
it with the current locked-sigs.inc Also adding SDK_INCLUDE_NATIVESDK 
tasklistfn to the logic surrounding setting tasklist file to not prune esdk 
sstate during creation

Signed-off-by: Jaewon Lee 
---
 meta/classes/populate_sdk_ext.bbclass | 28 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 ++--
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 40b0375..d98b0e5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
 SDK_EXT_TYPE ?= "full"
 SDK_INCLUDE_PKGDATA ?= "0"
 SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else 
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
 
 SDK_RECRDEP_TASKS ?= ""
 
@@ -401,9 +402,27 @@ python copy_buildsystem () {
 excluded_targets = get_sdk_install_targets(d, images_only=True)
 sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
 lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') + 
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+excluded_targets.split(),
+nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+sigfile,
+nativesigfile_pruned,
+sigfile)
+
 oe.copy_buildsystem.prune_lockedsigs([],
  excluded_targets.split(),
  sigfile,
+ False,
  lockedsigs_pruned)
 
 sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
 
 sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
 sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and 
not sdk_include_nativesdk:
 # Create the filtered task list used to generate the sstate cache 
shipped with the SDK
 tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath) @@ 
-658,9 +677,16 @@ fakeroot python do_populate_sdk_ext() {
 d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
 # ESDKs have a libc from the buildtools so ensure we don't ship linguas 
twice
 d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
 populate_sdk_common(d)
 }
 
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
 def get_ext_sdk_depends(d):
 # Note: the deps varflag is a list not a string, so we need to specify 
expand=False
 deps = d.getVarFlag('do_image_complete', 'deps', False) diff --git 
a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py index 
7cb784c..5bc728e 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -168,7 +168,7 @@ def generate_locked_sigs(sigfile, d):
 tasks = ['%s.%s' % (v[2], v[1]) for v in depd.values()]
 bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
 
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, 
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, 
pruned_output):
 with open(lockedsigs, 'r') as infile:
 bb.utils.mkdirhier(os.path.dirname(pruned_output))
 with 

[OE-core] [PATCH] fatresize_1.0.2.bb: Add recipe for fatresize command line tool

[Nathan Rossi]

The fatresize command line tool provides command line access to the
libparted-fs-resize library implementation of the FAT partition
resizing.

This tool is useful for safely resizing FAT partitions which are
commonly found as the boot partition on a variety of SoC targets (e.g.
RaspberryPi).

The Debian version of the source is used as the original upstream on
SourceForge is no longer actively maintained.

Signed-off-by: Nathan Rossi 
---
The reason for locating the recipe in the parted directory is that the
program itself does not implement the FAT partition resizing it is
merely exposing the functionality from libparted-fs-resize as a command
line tool.
---
 meta/recipes-extended/parted/fatresize_1.0.2.bb | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 meta/recipes-extended/parted/fatresize_1.0.2.bb

diff --git a/meta/recipes-extended/parted/fatresize_1.0.2.bb 
b/meta/recipes-extended/parted/fatresize_1.0.2.bb
new file mode 100644
index 00..a2f6b6d131
--- /dev/null
+++ b/meta/recipes-extended/parted/fatresize_1.0.2.bb
@@ -0,0 +1,15 @@
+SUMMARY = "Resize FAT partitions using libparted"
+SECTION = "console/tools"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+SRC_URI = "git://salsa.debian.org/parted-team/fatresize.git;protocol=https"
+SRCREV = "3f80afc76ad82d4a1b852a6c8dea24cd9f5e7a24"
+
+PV = "1.0.2-11-git+${SRCPV}"
+
+S = "${WORKDIR}/git"
+
+DEPENDS = "parted"
+
+inherit autotools pkgconfig
---
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] devtool: standard: Handle exporting generated config fragments

[Nathan Rossi]

The cml1 and ccmake bbclasses generate configuration fragment source
files that must be exported from the WORKDIR as a source file to be
preserved across builds. This change adds detection of the current
recipes inherited classes and for cml1 and ccmake classes checks for the
specific generated configuration fragment files. These files are then
exported by devtool and included as SRC_URI files from within the target
layer.

Signed-off-by: Nathan Rossi 
---
 scripts/lib/devtool/standard.py | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index ea09bbff31..0a1e329e61 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -1328,6 +1328,20 @@ def _export_local_files(srctree, rd, destdir, 
srctreebase):
 if os.path.exists(os.path.join(local_files_dir, fragment_fn)):
 os.unlink(os.path.join(local_files_dir, fragment_fn))
 
+# Special handling for cml1, ccmake, etc bbclasses that generated
+# configuration fragment files that are consumed as source files
+for frag_class, frag_name in [("cml1", "fragment.cfg"), ("ccmake", 
"site-file.cmake")]:
+if bb.data.inherits_class(frag_class, rd):
+srcpath = os.path.join(rd.getVar('WORKDIR'), frag_name)
+if os.path.exists(srcpath):
+if frag_name not in new_set:
+new_set.append(frag_name)
+# copy fragment into destdir
+shutil.copy2(srcpath, destdir)
+# copy fragment into local files if exists
+if os.path.isdir(local_files_dir):
+shutil.copy2(srcpath, local_files_dir)
+
 if new_set is not None:
 for fname in new_set:
 if fname in existing_files:
---
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] cmake-native: Enable ccmake by default and depend on ncurses

[Nathan Rossi]

Enable the building of the curses based ui for cmake. This depends on
ncurses.

Signed-off-by: Nathan Rossi 
---
This patch suggests enabling this in the cmake-native recipe, however
this might be undesirable for bootstrapping reasons. Whilst ccmake is
not used normally the added dependency on ncurses is likely required for
other parts of the build so impact on build ordering and time should be
relatively minimal.
---
 meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
index fedcf3d4bd..b2952ee5f5 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
@@ -1,7 +1,7 @@
 require cmake.inc
 inherit native
 
-DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native 
curl-native"
+DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native 
curl-native ncurses-native"
 
 SRC_URI += "file://OEToolchainConfig.cmake \
 file://environment.d-cmake.sh \
@@ -13,10 +13,9 @@ SRC_URI += "file://OEToolchainConfig.cmake \
 B = "${WORKDIR}/build"
 do_configure[cleandirs] = "${B}"
 
-# Disable ccmake since we don't depend on ncurses
 CMAKE_EXTRACONF = "\
 -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
--DBUILD_CursesDialog=0 \
+-DBUILD_CursesDialog=1 \
 -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
 -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
 -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \
---
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] ccmake.bbclass: Create a cml1 style class for the CMake curses UI

[Nathan Rossi]

The ccmake bbclass implements two tasks. The first task 'ccmake'
preserves the configured state of CMakeCache.txt (generated from the
configure task) and invokes the 'ccmake' program within a oe_terminal
execution. The user can then review, select and modify configuration
options and once satisfied with the configuration exit ccmake. Once
ccmake has exited the build can be run and the updated configuration
should be reflected in the output build.

The ccmake bbclass has a second task 'ccmake_diffconfig' to compute the
differences in configuration which was modified by ccmake. Since there
are many ways to persist the configuration changes within recipes and
layer configuration, the differences are emitted as a bitbake recipe
fragment (configuration.inc) using EXTRA_OECMAKE as well as a CMake
script file which can be used as a input to cmake via the '-C' argument.
Both files are generated in the WORKDIR of the build and the paths to
the files are written as output from the build. It is then up to the
user to take this configuration and apply it to the desired location.

Signed-off-by: Nathan Rossi 
---
 meta/classes/ccmake.bbclass | 97 +
 1 file changed, 97 insertions(+)
 create mode 100644 meta/classes/ccmake.bbclass

diff --git a/meta/classes/ccmake.bbclass b/meta/classes/ccmake.bbclass
new file mode 100644
index 00..933e122b35
--- /dev/null
+++ b/meta/classes/ccmake.bbclass
@@ -0,0 +1,97 @@
+inherit terminal
+
+python do_ccmake() {
+import shutil
+
+# copy current config for diffing
+config = os.path.join(d.getVar("B"), "CMakeCache.txt")
+if os.path.exists(config):
+shutil.copy(config, config + ".orig")
+
+oe_terminal(d.expand("ccmake ${OECMAKE_GENERATOR_ARGS} 
${OECMAKE_SOURCEPATH} -Wno-dev"),
+d.getVar("PN") + " - ccmake", d)
+
+if os.path.exists(config) and os.path.exists(config + ".orig"):
+if bb.utils.md5_file(config) != bb.utils.md5_file(config + ".orig"):
+# the cmake class uses cmake --build, which will by default
+# regenerate configuration, simply mark the compile step as tainted
+# to ensure it is re-run
+bb.note("Configuration changed, recompile will be forced")
+bb.build.write_taint('do_compile', d)
+
+}
+do_ccmake[depends] += "cmake-native:do_populate_sysroot"
+do_ccmake[nostamp] = "1"
+do_ccmake[dirs] = "${B}"
+addtask ccmake after do_configure
+
+def cmake_parse_config_cache(path):
+with open(path, "r") as f:
+for i in f:
+i = i.rstrip("\n")
+if len(i) == 0 or i.startswith("//") or i.startswith("#"):
+continue # empty or comment
+key, value = i.split("=", 1)
+key, keytype = key.split(":")
+if keytype in ["INTERNAL", "STATIC"]:
+continue # skip internal and static config options
+yield key, keytype, value
+
+def cmake_diff_config_vars(a, b):
+removed, added = [], []
+
+for ak, akt, av in a:
+found = False
+for bk, bkt, bv in b:
+if bk == ak:
+found = True
+if bkt != akt or bv != av: # changed
+removed.append((ak, akt, av))
+added.append((bk, bkt, bv))
+break
+# remove any missing from b
+if not found:
+removed.append((ak, akt, av))
+
+# add any missing from a
+for bk, bkt, bv in b:
+if not any(bk == ak for ak, akt, av in a):
+added.append((bk, bkt, bv))
+
+return removed, added
+
+python do_ccmake_diffconfig() {
+import shutil
+config = os.path.join(d.getVar("B"), "CMakeCache.txt")
+if os.path.exists(config) and os.path.exists(config + ".orig"):
+if bb.utils.md5_file(config) != bb.utils.md5_file(config + ".orig"):
+# scan the changed options
+old = list(cmake_parse_config_cache(config + ".orig"))
+new = list(cmake_parse_config_cache(config))
+_, added = cmake_diff_config_vars(old, new)
+
+if len(added) != 0:
+with open(d.expand("${WORKDIR}/configuration.inc"), "w") as f:
+f.write("EXTRA_OECMAKE += \" \\\n")
+for k, kt, v in added:
+escaped = v if " " not in v else "\"{0}\"".format(v)
+f.write("-D{0}:{1}={2} \\\n".format(k, kt, 
escaped))
+f.write("\"\n")
+bb.plain("Configuration recipe fragment written to: 
{0}".format(d.expand("${WORKDIR}/configuration.inc")))
+
+with open(d.expand("${WORKDIR}/site-file.cmake"), "w") as f:
+for k, kt, v in added:
+f.write("SET({0} \"{1}\" CACHE {2} "")\n".format(k, v, 
kt))
+bb.plain("Configuration cmake fragment written to: 
{0}".format(d.expand("${WORKDIR}/site-file.cmake")))
+
+# restore 

[OE-core] [PATCH 2/2] cml1.bbclass: Use POSIX sh instead of var-SHELL

[Nathan Rossi]

Use the default POSIX sh instead of relying of var-SHELL being set to a
compatible shell. Such that in cases where SHELL is set to a
incompatible shell (e.g. csh, zsh, fish, etc.) the terminal command does
not just silently fail.

Signed-off-by: Nathan Rossi 
---
 meta/classes/cml1.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 7f6df4011b..98d24cec74 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -26,7 +26,7 @@ python do_menuconfig() {
 except OSError:
 mtime = 0
 
-oe_terminal("${SHELL} -c \"make %s; if [ \\$? -ne 0 ]; then echo 'Command 
failed.'; printf 'Press any key to continue... '; read r; fi\"" % 
d.getVar('KCONFIG_CONFIG_COMMAND'),
+oe_terminal("sh -c \"make %s; if [ \\$? -ne 0 ]; then echo 'Command 
failed.'; printf 'Press any key to continue... '; read r; fi\"" % 
d.getVar('KCONFIG_CONFIG_COMMAND'),
 d.getVar('PN') + ' Configuration', d)
 
 # FIXME this check can be removed when the minimum bitbake version has 
been bumped
---
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] terminal.bbclass: Generate do_terminal as bitbake would

[Nathan Rossi]

This changes the runfile that is generated to have the same behaviour as
bitbake with regards to emitting the shebang and trap code. The existing
implementation used 'env' with the current var-SHELL. This means that if
the user has configured there system/environment with a alternate shell
(e.g. csh, zsh, fish, etc.) the do_terminal function would attempt to
execute with the wrong/incompatible shell and fail silently.

With this change devshell and other classes that rely on terminal can
now run when the var-SHELL is not set to a sh compatible shell. For
devshell, it will launch the devshell with the users configured shell.

Signed-off-by: Nathan Rossi 
---
 meta/classes/terminal.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
index 73e765d57a..6059ae95e0 100644
--- a/meta/classes/terminal.bbclass
+++ b/meta/classes/terminal.bbclass
@@ -14,6 +14,7 @@ def oe_terminal_prioritized():
 return " ".join(o.name for o in oe.terminal.prioritized())
 
 def emit_terminal_func(command, envdata, d):
+import bb.build
 cmd_func = 'do_terminal'
 
 envdata.setVar(cmd_func, 'exec ' + command)
@@ -25,8 +26,7 @@ def emit_terminal_func(command, envdata, d):
 bb.utils.mkdirhier(os.path.dirname(runfile))
 
 with open(runfile, 'w') as script:
-script.write('#!/usr/bin/env %s\n' % d.getVar('SHELL'))
-script.write('set -e\n')
+script.write(bb.build.shell_trap_code())
 bb.data.emit_func(cmd_func, script, envdata)
 script.write(cmd_func)
 script.write("\n")
---
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PULL][PATCH 0/2] Implement debian packages GPG signing

[Alexander Kanavin]

Yes, that is fine. Let me know if something is not clear in that test case.

Btw, the apt version we have is badly out of date (and has a significant 
security issue I think) so if you can update that, that’d be awesome.

Alex

> On 2 Apr 2019, at 9.36, Xavier Berger  wrote:
> 
> Hi Alexender, 
> 
> I'm working on test case but I've a lot of things to understand (and setup to 
> perform).
> I'm basically taking dnf as example and creating a test for apt. Please let 
> me know if you think my strategy is not correct.
> 
> I'll let you know here when it will work.
> 
> Xavier
> 
> -Original Message-
> From: Alexander Kanavin  
> Sent: lundi 1 avril 2019 16:50
> To: Xavier Berger 
> Cc: OE-core 
> Subject: Re: [OE-core] [PULL][PATCH 0/2] Implement debian packages GPG signing
> 
>> On Mon, 1 Apr 2019 at 15:57, Xavier Berger  
>> wrote:
>> Xavier Berger (2):
>>  gpg-sign: Add parameters to gpg signature function
>>  package_manager: sign DEB package feeds
>> 
>> meta/lib/oe/gpg_sign.py|  6 +-
>> meta/lib/oe/package_manager.py | 19 ---
> 
> How do we make sure this does not regress? Can you add a test case similar to 
> one for rpm feed signing?
> 
> Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] avahi: fix CVE-2017-6519

[Kang Kai]

On 2019/4/2 下午3:46, Burton, Ross wrote:

The patch itself says two CVE IDs, so can you put them both in the
path header with your SOB please?


I have checked CVE-2018-1000845 which is rejected that it is duplicate 
of CVE-2017-6519. That why didn't list CVE-2018-1000845 in patch and 
commit message.


Regards,
Kai




Ross

On Tue, 2 Apr 2019 at 08:45,  wrote:

From: Kai Kang 

Backport patch to fix CVE-2017-6519.

CVE: CVE-2017-6519

Signed-off-by: Kai Kang 
---
  meta/recipes-connectivity/avahi/avahi.inc |  4 +-
  .../avahi/files/fix-CVE-2017-6519.patch   | 48 +++
  2 files changed, 51 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch

diff --git a/meta/recipes-connectivity/avahi/avahi.inc 
b/meta/recipes-connectivity/avahi/avahi.inc
index 11846849f0..8339e451f5 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -19,7 +19,9 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
  
file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
  
file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"

-SRC_URI = 
"https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz;
+SRC_URI = 
"https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz \
+   file://fix-CVE-2017-6519.patch \
+   "

  UPSTREAM_CHECK_URI = "https://github.com/lathiat/avahi/releases/;
  SRC_URI[md5sum] = "d76c59d0882ac6c256d70a2a585362a6"
diff --git a/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch 
b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
new file mode 100644
index 00..7461fe193d
--- /dev/null
+++ b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
@@ -0,0 +1,48 @@
+Upstream-Status: Backport [https://github.com/lathiat/avahi/commit/e111def]
+
+CVE: CVE-2017-6519
+
+Signed-off-by: Kai Kang 
+
+From e111def44a7df4624a4aa3f85fe98054bffb6b4f Mon Sep 17 00:00:00 2001
+From: Trent Lloyd 
+Date: Sat, 22 Dec 2018 09:06:07 +0800
+Subject: [PATCH] Drop legacy unicast queries from address not on local link
+
+When handling legacy unicast queries, ensure that the source IP is
+inside a subnet on the local link, otherwise drop the packet.
+
+Fixes #145
+Fixes #203
+CVE-2017-6519
+CVE-2018-1000845
+---
+ avahi-core/server.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/avahi-core/server.c b/avahi-core/server.c
+index a2cb19a8..a2580e38 100644
+--- a/avahi-core/server.c
 b/avahi-core/server.c
+@@ -930,6 +930,7 @@ static void dispatch_packet(AvahiServer *s, AvahiDnsPacket 
*p, const AvahiAddres
+
+ if (avahi_dns_packet_is_query(p)) {
+ int legacy_unicast = 0;
++char t[AVAHI_ADDRESS_STR_MAX];
+
+ /* For queries EDNS0 might allow ARCOUNT != 0. We ignore the
+  * AR section completely here, so far. Until the day we add
+@@ -947,6 +948,13 @@ static void dispatch_packet(AvahiServer *s, 
AvahiDnsPacket *p, const AvahiAddres
+ legacy_unicast = 1;
+ }
+
++if (!is_mdns_mcast_address(dst_address) &&
++!avahi_interface_address_on_link(i, src_address)) {
++
++avahi_log_debug("Received non-local unicast query from host %s on interface 
'%s.%i'.", avahi_address_snprint(t, sizeof(t), src_address), i->hardware->name, 
i->protocol);
++return;
++}
++
+ if (legacy_unicast)
+ reflect_legacy_unicast_query_packet(s, p, i, src_address, port);
+
--
2.20.0

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Kai Kang

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] asciidoc: use Python 3 port

[Burton, Ross]

Ah so it looks like it's ignoring the XML stuff we're installing and
using the host, and you don't have the right versions.  Shall look
into this today.

Ross

On Tue, 2 Apr 2019 at 03:34, Khem Raj  wrote:
>
> I find many posts reporting similar issue also I see it happen on
> ubuntu 18.04 host as well
>
> https://groups.google.com/forum/#!topic/asciidoc/FC-eOwU8rYg
> https://groups.google.com/forum/#!topic/asciidoc/N4boYdQ3Zik
>
> On Mon, Apr 1, 2019 at 7:01 AM Burton, Ross  wrote:
> >
> > Error 4 is 'validation error', can you recover the file that is failing?
> >
> > Ross
> >
> > On Sat, 30 Mar 2019 at 02:01, Khem Raj  wrote:
> > >
> > > On Wed, Mar 27, 2019 at 7:20 AM Ross Burton  wrote:
> > > >
> > > > There's a sort-of-official port of asciidoc to Python 3.  Whilst the 
> > > > official
> > > > replacement is asciidoctor which is rewritten in Ruby, this is a fairly 
> > > > trivial
> > > > swap and removes Python 2 from core-image-sato builds entirely.
> > > >
> > > > Moving forward we should evaluate asciidoctor, but that can wait.
> > > >
> > > > Change the RDEPENDS so that python3 is only a dependency for target and
> > > > nativesdk builds, for native this can use the host python3.
> > > >
> > > > Remove redundant DESTDIR export that isn't needed.
> > > >
> > >
> > > its failing on my archlinux builder, ideas ?
> > >
> > > https://errors.yoctoproject.org/Errors/Details/234833/
> > > https://errors.yoctoproject.org/Errors/Details/234829/
> > >
> > > > Signed-off-by: Ross Burton 
> > > > ---
> > > >  meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb | 21 
> > > > -
> > > >  1 file changed, 12 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb 
> > > > b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
> > > > index 38164d55735..d0d15171ac4 100644
> > > > --- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
> > > > +++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
> > > > @@ -8,17 +8,20 @@ LICENSE = "GPLv2"
> > > >  LIC_FILES_CHKSUM = 
> > > > "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
> > > >  
> > > > file://COPYRIGHT;md5=029ad5428ba5efa20176b396222d4069"
> > > >
> > > > -SRC_URI = 
> > > > "http://downloads.sourceforge.net/project/${BPN}/${BPN}/${PV}/${BP}.tar.gz;
> > > > -SRC_URI[md5sum] = "c59018f105be8d022714b826b0be130a"
> > > > -SRC_URI[sha256sum] = 
> > > > "78db9d0567c8ab6570a6eff7ffdf84eadd91f2dfc0a92a2d0105d323cab4e1f0"
> > > > +SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https"
> > > > +SRCREV = "618f6e6f6b558ed1e5f2588cd60a5a6b4f881ca0"
> > > > +PV .= "+py3-git${SRCPV}"
> > > >
> > > > -UPSTREAM_CHECK_URI = "https://sourceforge.net/projects/asciidoc/files/;
> > > > +DEPENDS = "libxml2-native libxslt-native docbook-xml-dtd4-native"
> > > >
> > > > +S = "${WORKDIR}/git"
> > > > +
> > > > +# Not using automake
> > > >  inherit autotools-brokensep
> > > > +CLEANBROKEN = "1"
> > > >
> > > > -export DESTDIR = "${D}"
> > > > -DEPENDS_class-native = "docbook-xml-dtd4-native"
> > > > -RDEPENDS_${PN} += "python"
> > > > -BBCLASSEXTEND = "native"
> > > > +# target and nativesdk needs python3, but for native we can use the 
> > > > host.
> > > > +RDEPENDS_${PN} += "python3"
> > > > +RDEPENDS_remove_class-native = "python3"
> > > >
> > > > -CLEANBROKEN = "1"
> > > > +BBCLASSEXTEND = "native nativesdk"
> > > > --
> > > > 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 1/2] avahi: fix CVE-2017-6519

[Burton, Ross]

The patch itself says two CVE IDs, so can you put them both in the
path header with your SOB please?

Ross

On Tue, 2 Apr 2019 at 08:45,  wrote:
>
> From: Kai Kang 
>
> Backport patch to fix CVE-2017-6519.
>
> CVE: CVE-2017-6519
>
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-connectivity/avahi/avahi.inc |  4 +-
>  .../avahi/files/fix-CVE-2017-6519.patch   | 48 +++
>  2 files changed, 51 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
>
> diff --git a/meta/recipes-connectivity/avahi/avahi.inc 
> b/meta/recipes-connectivity/avahi/avahi.inc
> index 11846849f0..8339e451f5 100644
> --- a/meta/recipes-connectivity/avahi/avahi.inc
> +++ b/meta/recipes-connectivity/avahi/avahi.inc
> @@ -19,7 +19,9 @@ LIC_FILES_CHKSUM = 
> "file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
>  
> file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
>  
> file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"
>
> -SRC_URI = 
> "https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz;
> +SRC_URI = 
> "https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz 
> \
> +   file://fix-CVE-2017-6519.patch \
> +   "
>
>  UPSTREAM_CHECK_URI = "https://github.com/lathiat/avahi/releases/;
>  SRC_URI[md5sum] = "d76c59d0882ac6c256d70a2a585362a6"
> diff --git a/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch 
> b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
> new file mode 100644
> index 00..7461fe193d
> --- /dev/null
> +++ b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
> @@ -0,0 +1,48 @@
> +Upstream-Status: Backport [https://github.com/lathiat/avahi/commit/e111def]
> +
> +CVE: CVE-2017-6519
> +
> +Signed-off-by: Kai Kang 
> +
> +From e111def44a7df4624a4aa3f85fe98054bffb6b4f Mon Sep 17 00:00:00 2001
> +From: Trent Lloyd 
> +Date: Sat, 22 Dec 2018 09:06:07 +0800
> +Subject: [PATCH] Drop legacy unicast queries from address not on local link
> +
> +When handling legacy unicast queries, ensure that the source IP is
> +inside a subnet on the local link, otherwise drop the packet.
> +
> +Fixes #145
> +Fixes #203
> +CVE-2017-6519
> +CVE-2018-1000845
> +---
> + avahi-core/server.c | 8 
> + 1 file changed, 8 insertions(+)
> +
> +diff --git a/avahi-core/server.c b/avahi-core/server.c
> +index a2cb19a8..a2580e38 100644
> +--- a/avahi-core/server.c
>  b/avahi-core/server.c
> +@@ -930,6 +930,7 @@ static void dispatch_packet(AvahiServer *s, 
> AvahiDnsPacket *p, const AvahiAddres
> +
> + if (avahi_dns_packet_is_query(p)) {
> + int legacy_unicast = 0;
> ++char t[AVAHI_ADDRESS_STR_MAX];
> +
> + /* For queries EDNS0 might allow ARCOUNT != 0. We ignore the
> +  * AR section completely here, so far. Until the day we add
> +@@ -947,6 +948,13 @@ static void dispatch_packet(AvahiServer *s, 
> AvahiDnsPacket *p, const AvahiAddres
> + legacy_unicast = 1;
> + }
> +
> ++if (!is_mdns_mcast_address(dst_address) &&
> ++!avahi_interface_address_on_link(i, src_address)) {
> ++
> ++avahi_log_debug("Received non-local unicast query from host %s 
> on interface '%s.%i'.", avahi_address_snprint(t, sizeof(t), src_address), 
> i->hardware->name, i->protocol);
> ++return;
> ++}
> ++
> + if (legacy_unicast)
> + reflect_legacy_unicast_query_packet(s, p, i, src_address, port);
> +
> --
> 2.20.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

[OE-core] [PATCH 1/2] avahi: fix CVE-2017-6519

[kai.kang]

From: Kai Kang 

Backport patch to fix CVE-2017-6519.

CVE: CVE-2017-6519

Signed-off-by: Kai Kang 
---
 meta/recipes-connectivity/avahi/avahi.inc |  4 +-
 .../avahi/files/fix-CVE-2017-6519.patch   | 48 +++
 2 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch

diff --git a/meta/recipes-connectivity/avahi/avahi.inc 
b/meta/recipes-connectivity/avahi/avahi.inc
index 11846849f0..8339e451f5 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -19,7 +19,9 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
 
file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
 
file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"
 
-SRC_URI = 
"https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz;
+SRC_URI = 
"https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz \
+   file://fix-CVE-2017-6519.patch \
+   "
 
 UPSTREAM_CHECK_URI = "https://github.com/lathiat/avahi/releases/;
 SRC_URI[md5sum] = "d76c59d0882ac6c256d70a2a585362a6"
diff --git a/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch 
b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
new file mode 100644
index 00..7461fe193d
--- /dev/null
+++ b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
@@ -0,0 +1,48 @@
+Upstream-Status: Backport [https://github.com/lathiat/avahi/commit/e111def]
+
+CVE: CVE-2017-6519
+
+Signed-off-by: Kai Kang 
+
+From e111def44a7df4624a4aa3f85fe98054bffb6b4f Mon Sep 17 00:00:00 2001
+From: Trent Lloyd 
+Date: Sat, 22 Dec 2018 09:06:07 +0800
+Subject: [PATCH] Drop legacy unicast queries from address not on local link
+
+When handling legacy unicast queries, ensure that the source IP is
+inside a subnet on the local link, otherwise drop the packet.
+
+Fixes #145
+Fixes #203
+CVE-2017-6519
+CVE-2018-1000845
+---
+ avahi-core/server.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/avahi-core/server.c b/avahi-core/server.c
+index a2cb19a8..a2580e38 100644
+--- a/avahi-core/server.c
 b/avahi-core/server.c
+@@ -930,6 +930,7 @@ static void dispatch_packet(AvahiServer *s, AvahiDnsPacket 
*p, const AvahiAddres
+ 
+ if (avahi_dns_packet_is_query(p)) {
+ int legacy_unicast = 0;
++char t[AVAHI_ADDRESS_STR_MAX];
+ 
+ /* For queries EDNS0 might allow ARCOUNT != 0. We ignore the
+  * AR section completely here, so far. Until the day we add
+@@ -947,6 +948,13 @@ static void dispatch_packet(AvahiServer *s, 
AvahiDnsPacket *p, const AvahiAddres
+ legacy_unicast = 1;
+ }
+ 
++if (!is_mdns_mcast_address(dst_address) &&
++!avahi_interface_address_on_link(i, src_address)) {
++
++avahi_log_debug("Received non-local unicast query from host %s on 
interface '%s.%i'.", avahi_address_snprint(t, sizeof(t), src_address), 
i->hardware->name, i->protocol);
++return;
++}
++
+ if (legacy_unicast)
+ reflect_legacy_unicast_query_packet(s, p, i, src_address, port);
+ 
-- 
2.20.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] webkitgtk: 2.22.6 -> 2.22.7

[kai.kang]

From: Kai Kang 

webkitgtk 2.22.7 is a bug fix release in the stable 2.22 series.

* Fix rendering of glyphs in Hebrew (and possibly other languages) when
  Unicode NFC normalization is used.
* Fix several crashes and race conditions.

See https://www.webkitgtk.org/2019/03/01/webkitgtk2.22.7-released.html

Signed-off-by: Kai Kang 
---
 .../webkit/{webkitgtk_2.22.6.bb => webkitgtk_2.22.7.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-sato/webkit/{webkitgtk_2.22.6.bb => webkitgtk_2.22.7.bb} 
(97%)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.22.6.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.22.7.bb
similarity index 97%
rename from meta/recipes-sato/webkit/webkitgtk_2.22.6.bb
rename to meta/recipes-sato/webkit/webkitgtk_2.22.7.bb
index 35c70e0d02..301bf10cea 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.22.6.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.22.7.bb
@@ -23,8 +23,8 @@ SRC_URI = 
"http://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
file://bad_optional_access.patch \
"
 
-SRC_URI[md5sum] = "7c21a30f7f078f0b712caf0c7ee966a4"
-SRC_URI[sha256sum] = 
"df90db9c0db0a2072b945fa3e1d45865922bd686c4659cce6cb5897ce357c85b"
+SRC_URI[md5sum] = "47386c10a9c3975f933c85404f35ff3b"
+SRC_URI[sha256sum] = 
"4be6f7d605cd0a690fd26e8aa83b089a33ad9d419148eafcfb60580dd2af30ff"
 
 inherit cmake pkgconfig gobject-introspection perlnative distro_features_check 
upstream-version-is-even gtk-doc
 
-- 
2.20.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PULL][PATCH 0/2] Implement debian packages GPG signing

[Xavier Berger]

Hi Alexender, 

I'm working on test case but I've a lot of things to understand (and setup to 
perform).
I'm basically taking dnf as example and creating a test for apt. Please let me 
know if you think my strategy is not correct.

I'll let you know here when it will work.

Xavier

-Original Message-
From: Alexander Kanavin  
Sent: lundi 1 avril 2019 16:50
To: Xavier Berger 
Cc: OE-core 
Subject: Re: [OE-core] [PULL][PATCH 0/2] Implement debian packages GPG signing

On Mon, 1 Apr 2019 at 15:57, Xavier Berger  wrote:
> Xavier Berger (2):
>   gpg-sign: Add parameters to gpg signature function
>   package_manager: sign DEB package feeds
>
>  meta/lib/oe/gpg_sign.py|  6 +-
>  meta/lib/oe/package_manager.py | 19 ---

How do we make sure this does not regress? Can you add a test case similar to 
one for rpm feed signing?

Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glib-networking: remove PACKAGECONFIG for gnutls

[Alexander Kanavin]

This option was re-instated in 2.60, can you add a comment to the recipe 
please? So that when it’s upgraded, gnutls is again optional.

Alex

> On 2 Apr 2019, at 0.28, Andreas Müller  wrote:
> 
> * with patch suggested in [1] build complains with:
>  | ERROR: glib-networking-2.58.0-r0 do_configure: QA Issue: glib-networking: 
> configure was passed unrecognised options: gnutls [unknown-configure-option]
> * it turned mandatory - see meson.build:
>  | # *** Checks for GnuTLS ***
>  | gnutls_dep = dependency('gnutls', version: '>= 3.4.4', required: true)
> 
> [1] 
> http://lists.openembedded.org/pipermail/openembedded-core/2019-April/280693.html
> 
> Signed-off-by: Andreas Müller 
> ---
> meta/recipes-core/glib-networking/glib-networking_2.58.0.bb | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb 
> b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> index f3190e1cae0..a4138d67cc6 100644
> --- a/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> +++ b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> @@ -7,14 +7,11 @@ LICENSE = "LGPLv2.1"
> LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
> 
> SECTION = "libs"
> -DEPENDS = "glib-2.0"
> +DEPENDS = "glib-2.0 gnutls"
> 
> SRC_URI[archive.md5sum] = "75b14b7e73a67753be9ce307751c661d"
> SRC_URI[archive.sha256sum] = 
> "bdfa0255e031b8ee003cc283002536b77ee76450105f1dc6ab066b9bf4330068"
> 
> -PACKAGECONFIG ??= "gnutls"
> -
> -PACKAGECONFIG[gnutls] = "-Dgnutls=true,-Dgnutls=false,gnutls"
> PACKAGECONFIG[libproxy] = 
> "-Dlibproxy_support=true,-Dlibproxy_support=false,libproxy"
> 
> EXTRA_OEMESON = "-Dgnome_proxy_support=false"
> -- 
> 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] [thud][PATCH] Revert "boost: update to 1.69.0"

[Martin Jansa]

Any update on this one? Or should we downgrade it on our side when bumping
oe-core/thud revision?

On Sun, Mar 24, 2019 at 7:48 PM Martin Jansa  wrote:

> On Sun, Mar 24, 2019 at 11:45:08AM -0700, akuster808 wrote:
> >
> >
> > On 3/24/19 11:01 AM, Martin Jansa wrote:
> > > On Tue, Mar 19, 2019 at 07:52:06AM +, mikko.rap...@bmw.de wrote:
> > >> On Mon, Mar 18, 2019 at 06:03:05PM +0100, Andreas Müller wrote:
> > >>> On Mon, Mar 18, 2019 at 5:45 PM Armin Kuster 
> wrote:
> >  This reverts commit a384248938ea9db096866bf4ec8678d35ca62a12.
> > 
> >  This package update slipped in doing the maint process. Removing it.
> > >> 
> > >>> Just my opinion - don't consider this as NAK.
> > >>>
> > >>> * I already fixed the recipes that failed for me. For at least one
> the
> > >>> change is no more compatible to 1.68.0.
> > >>> * This makes PV going backwards
> > >>>
> > >>> Thanks for addressing - what do others think?
> > >> I'm not using thud yet, but updating boost in stable branch would
> break
> > >> too many things and I would have to revert that change in our trees.
> Some boost
> > >> updates are in the end quite trivial and just require recompiling
> > >> everything but still, I would prefer that boost is not updated in
> stable
> > >> branches unless there is a huge security/stability issue with the old
> version.
> > > Agreed.
> > >
> > > I care less for PV going backwards nowadays, it's probably less
> annoying than
> > > bumping PE first in master and then backporting PE bump to thud.
> > >
> > > People with build issues related to boost upgrade probably never
> > > built whole image to push it as an upgrade to end devices.
> >
> > So do you agree with the revert?
>
> I do.
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] resulttool/merge: Enable turn off testseries configuration creation

[Yeoh Ee Peng]

Testseries configuration has important implication to report and
regression. Enable turn off testseries configuration creation
during results merge.

Signed-off-by: Yeoh Ee Peng 
---
 scripts/lib/resulttool/merge.py   | 13 +++--
 scripts/lib/resulttool/resultutils.py | 10 +-
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/scripts/lib/resulttool/merge.py b/scripts/lib/resulttool/merge.py
index 3e4b7a3..5fffb54 100644
--- a/scripts/lib/resulttool/merge.py
+++ b/scripts/lib/resulttool/merge.py
@@ -18,15 +18,15 @@ import resulttool.resultutils as resultutils
 
 def merge(args, logger):
 if os.path.isdir(args.target_results):
-results = resultutils.load_resultsdata(args.target_results, 
configmap=resultutils.store_map)
-resultutils.append_resultsdata(results, args.base_results, 
configmap=resultutils.store_map)
+results = resultutils.load_resultsdata(args.target_results, 
configmap=resultutils.store_map, add_testseries=args.off_add_testseries)
+resultutils.append_resultsdata(results, args.base_results, 
configmap=resultutils.store_map, add_testseries=args.off_add_testseries)
 resultutils.save_resultsdata(results, args.target_results)
 else:
-results = resultutils.load_resultsdata(args.base_results, 
configmap=resultutils.flatten_map)
+results = resultutils.load_resultsdata(args.base_results, 
configmap=resultutils.flatten_map, add_testseries=args.off_add_testseries)
 if os.path.exists(args.target_results):
-resultutils.append_resultsdata(results, args.target_results, 
configmap=resultutils.flatten_map)
+resultutils.append_resultsdata(results, args.target_results, 
configmap=resultutils.flatten_map, add_testseries=args.off_add_testseries)
 resultutils.save_resultsdata(results, 
os.path.dirname(args.target_results), fn=os.path.basename(args.target_results))
-
+logger.info('Merged results to %s' % os.path.dirname(args.target_results))
 return 0
 
 def register_commands(subparsers):
@@ -39,4 +39,5 @@ def register_commands(subparsers):
   help='the results file/directory to import')
 parser_build.add_argument('target_results',
   help='the target file or directory to merge the 
base_results with')
-
+parser_build.add_argument('-o', '--off-add-testseries', 
action='store_false',
+  help='turn off add testseries configuration to 
results')
diff --git a/scripts/lib/resulttool/resultutils.py 
b/scripts/lib/resulttool/resultutils.py
index 153f2b8..4318ee7 100644
--- a/scripts/lib/resulttool/resultutils.py
+++ b/scripts/lib/resulttool/resultutils.py
@@ -42,7 +42,7 @@ store_map = {
 #
 # Load the json file and append the results data into the provided results dict
 #
-def append_resultsdata(results, f, configmap=store_map):
+def append_resultsdata(results, f, configmap=store_map, add_testseries=True):
 if type(f) is str:
 with open(f, "r") as filedata:
 data = json.load(filedata)
@@ -51,7 +51,7 @@ def append_resultsdata(results, f, configmap=store_map):
 for res in data:
 if "configuration" not in data[res] or "result" not in data[res]:
 raise ValueError("Test results data without configuration or 
result section?")
-if "TESTSERIES" not in data[res]["configuration"]:
+if add_testseries and "TESTSERIES" not in data[res]["configuration"]:
 data[res]["configuration"]["TESTSERIES"] = 
os.path.basename(os.path.dirname(f))
 testtype = data[res]["configuration"].get("TEST_TYPE")
 if testtype not in configmap:
@@ -72,16 +72,16 @@ def append_resultsdata(results, f, configmap=store_map):
 # Walk a directory and find/load results data
 # or load directly from a file
 #
-def load_resultsdata(source, configmap=store_map):
+def load_resultsdata(source, configmap=store_map, add_testseries=True):
 results = {}
 if os.path.isfile(source):
-append_resultsdata(results, source, configmap)
+append_resultsdata(results, source, configmap, add_testseries)
 return results
 for root, dirs, files in os.walk(source):
 for name in files:
 f = os.path.join(root, name)
 if name == "testresults.json":
-append_resultsdata(results, f, configmap)
+append_resultsdata(results, f, configmap, add_testseries)
 return results
 
 def filter_resultsdata(results, resultid):
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] resulttool: Enable report for single result file

[Yeoh Ee Peng]

Current validation check function inside resulttool disallow the
report for single result file although the underlying library
was able to handle both directory and file as source input to report.
Removed the validation check as it was no longer needed and to
enable report for single result file.

Signed-off-by: Yeoh Ee Peng 
---
 scripts/resulttool | 10 --
 1 file changed, 10 deletions(-)

diff --git a/scripts/resulttool b/scripts/resulttool
index 5a89e1c..18ac101 100755
--- a/scripts/resulttool
+++ b/scripts/resulttool
@@ -51,13 +51,6 @@ import resulttool.report
 import resulttool.manualexecution
 logger = scriptutils.logger_create('resulttool')
 
-def _validate_user_input_arguments(args):
-if hasattr(args, "source_dir"):
-if not os.path.isdir(args.source_dir):
-logger.error('source_dir argument need to be a directory : %s' % 
args.source_dir)
-return False
-return True
-
 def main():
 parser = argparse_oe.ArgumentParser(description="OEQA test result 
manipulation tool.",
 epilog="Use %(prog)s  
--help to get help on a specific command")
@@ -80,9 +73,6 @@ def main():
 elif args.quiet:
 logger.setLevel(logging.ERROR)
 
-if not _validate_user_input_arguments(args):
-return -1
-
 try:
 ret = args.func(args, logger)
 except argparse_oe.ArgumentUsageError as ae:
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Git commit process question.

[Adrian Bunk]

On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> 
> 
> On 4/1/19 4:02 PM, Richard Purdie wrote:
> > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >> Hello,
> >>
> >> I have noticed a large number of git commits with no header
> >> information being accepted.
> > Can you be more specific about what "no header information" means? You
> > mean a shortlog and no full log message?
> Commits with just a "subject" and signoff. No additional information
> 
> We tend to reference back to how the kernel does things.
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> These two sections in particular.
> 
> 
> 2) Describe your changes
> 
> Describe your problem. Whether your patch is a one-line bug fix or 5000
> lines of a new feature, there must be an underlying problem that
> motivated you to do this work. Convince the reviewer that there is a
> problem worth fixing and that it makes sense for them to read past the
> first paragraph.
>...

The kernel does not have "upgrade foo to the latest upstream version" commits.

With the Automatic Upgrade Helper this is a semi-automatic task, and 
most of the time there is no specific motivation other than upgrading
to the latest upstream version.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core