[OE-core] [PATCH] sqlite3:upgrade 3.28.0 -> 3.29.0
-Upgrade from sqlite3_3.28.0.bb to sqlite3_3.29.0.bb.
Signed-off-by: Zang Ruochen
---
meta/recipes-support/sqlite/{sqlite3_3.28.0.bb => sqlite3_3.29.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/sqlite/{sqlite3_3.28.0.bb => sqlite3_3.29.0.bb}
(58%)
diff --git a/meta/recipes-support/sqlite/sqlite3_3.28.0.bb
b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb
similarity index 58%
rename from meta/recipes-support/sqlite/sqlite3_3.28.0.bb
rename to meta/recipes-support/sqlite/sqlite3_3.29.0.bb
index 438a4ea..07e36be 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.28.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb
@@ -4,5 +4,5 @@ LICENSE = "PD"
LIC_FILES_CHKSUM =
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
SRC_URI = "http://www.sqlite.org/2019/sqlite-autoconf-${SQLITE_PV}.tar.gz;
-SRC_URI[md5sum] = "3c68eb400f8354605736cd55400e1572"
-SRC_URI[sha256sum] =
"d61b5286f062adfce5125eaf544d495300656908e61fca143517afcc0a89b7c3"
+SRC_URI[md5sum] = "8f3dfe83387e62ecb91c7c5c09c688dc"
+SRC_URI[sha256sum] =
"8e7c1e2950b5b04c5944a981cb31fffbf9d2ddda939d536838ebc854481afd5b"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for "[master] devtool/standard.py: ..." and 2 more
== Series Details == Series: "[master] devtool/standard.py: ..." and 2 more Revision: 1 URL : https://patchwork.openembedded.org/series/18609/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patch[master, 1/3] devtool/standard.py: Update devtool modify to copy source from work-shared if its already downloaded Issue Commit shortlog is too long [test_shortlog_length] Suggested fixEdit shortlog so that it is 90 characters or less (currently 100 characters) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][PATCH 1/3] devtool/standard.py: Update devtool modify to copy source from work-shared if its already downloaded
In the regular devtool modify flow, the kernel source is fetched by
running do_fetch task. This is an overhead in time and space.
This patch updates modify command to check if the kernel source is
already downloaded. If so, then instead of calling do_fetch, copy the
source from work-shared to devtool workspace by creating hard links
else run the usual devtool modify flow and call do_fetch task.
[YOCTO #10416]
Signed-off-by: Sai Hari Chandana Kalluri
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
scripts/lib/devtool/standard.py | 122
1 file changed, 99 insertions(+), 23 deletions(-)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 47ed531..2ac14b8 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -461,6 +461,31 @@ def sync(args, config, basepath, workspace):
finally:
tinfoil.shutdown()
+def symlink_oelocal_files_srctree(rd,srctree):
+ import oe.patch
+ if os.path.abspath(rd.getVar('S')) == os.path.abspath(rd.getVar('WORKDIR')):
+ # If recipe extracts to ${WORKDIR}, symlink the files into the srctree
+ # (otherwise the recipe won't build as expected)
+ local_files_dir = os.path.join(srctree, 'oe-local-files')
+ addfiles = []
+ for root, _, files in os.walk(local_files_dir):
+ relpth = os.path.relpath(root, local_files_dir)
+ if relpth != '.':
+ bb.utils.mkdirhier(os.path.join(srctree, relpth))
+ for fn in files:
+ if fn == '.gitignore':
+ continue
+ destpth = os.path.join(srctree, relpth, fn)
+ if os.path.exists(destpth):
+ os.unlink(destpth)
+ os.symlink('oe-local-files/%s' % fn, destpth)
+ addfiles.append(os.path.join(relpth, fn))
+ if addfiles:
+bb.process.run('git add %s' % ' '.join(addfiles), cwd=srctree)
+ useroptions = []
+ oe.patch.GitApplyTree.gitCommandUserOptions(useroptions, d=rd)
+ bb.process.run('git %s commit -a -m "Committing local file
symlinks\n\n%s"' % (' '.join(useroptions),
oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
+
def _extract_source(srctree, keep_temp, devbranch, sync, config, basepath,
workspace, fixed_setup, d, tinfoil, no_overrides=False):
"""Extract sources of a recipe"""
@@ -617,29 +642,7 @@ def _extract_source(srctree, keep_temp, devbranch, sync,
config, basepath, works
shutil.move(tempdir_localdir, srcsubdir)
shutil.move(srcsubdir, srctree)
-
-if os.path.abspath(d.getVar('S')) ==
os.path.abspath(d.getVar('WORKDIR')):
-# If recipe extracts to ${WORKDIR}, symlink the files into the
srctree
-# (otherwise the recipe won't build as expected)
-local_files_dir = os.path.join(srctree, 'oe-local-files')
-addfiles = []
-for root, _, files in os.walk(local_files_dir):
-relpth = os.path.relpath(root, local_files_dir)
-if relpth != '.':
-bb.utils.mkdirhier(os.path.join(srctree, relpth))
-for fn in files:
-if fn == '.gitignore':
-continue
-destpth = os.path.join(srctree, relpth, fn)
-if os.path.exists(destpth):
-os.unlink(destpth)
-os.symlink('oe-local-files/%s' % fn, destpth)
-addfiles.append(os.path.join(relpth, fn))
-if addfiles:
-bb.process.run('git add %s' % ' '.join(addfiles),
cwd=srctree)
-useroptions = []
-oe.patch.GitApplyTree.gitCommandUserOptions(useroptions, d=d)
-bb.process.run('git %s commit -a -m "Committing local file
symlinks\n\n%s"' % (' '.join(useroptions),
oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
+symlink_oelocal_files_srctree(d,srctree)
if is_kernel_yocto:
logger.info('Copying kernel config to srctree')
@@ -707,11 +710,31 @@ def _check_preserve(config, recipename):
tf.write(line)
os.rename(newfile, origfile)
+def get_staging_kver(srcdir):
+ #Kernel version from work-shared
+ kerver = []
+ staging_kerVer=""
+ if os.path.exists(srcdir) and os.listdir(srcdir):
+with open(os.path.join(srcdir,"Makefile")) as f:
+ version = [next(f) for x in range(5)][1:4]
+ for word in version:
+ kerver.append(word.split('= ')[1].split('\n')[0])
+ staging_kerVer = ".".join(kerver)
+ return staging_kerVer
+
+def get_staging_kbranch(srcdir):
+ staging_kbranch = ""
+ if os.path.exists(srcdir) and os.listdir(srcdir):
+
Re: [OE-core] [PATCH 3/5] cmake.bbclass: append includedir to implicit include dirs
An error in my analysis below: We *do* delete the dependency files in
the in-tree build case as well. The side-effect is masked in both
in-tree and out-of-tree build cases except here at Tait, where we don't
delete the entire build at configure time, due to a 20min+ rebuild time,
even with the benefit of icecc.
The rest of my concern still applies: This setting has no effect in the
target case, and only an unfortunate side effect in the -native case.
I'm not clear what the benefit is.
On 11/07/19 2:51 PM, Douglas Royds wrote:
This commit is having an unintended side-effect in the -native (and
probably nativesdk) case.
In the target build, $includedir is normally /usr/include,
fully-qualified. This path is already in CMake's list of implicit
include directories, and we don't include any header files from the
build PC's /usr/include in a target build in any case. This addition
to CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES has no effect.
In the -native case, the $includedir is set to STAGING_INCDIR_NATIVE,
but this path has already been added to the BUILD_CPPFLAGS as a system
include directory, so there will already be no warnings for any header
file in the STAGING_INCDIR_NATIVE.
There is a nasty side-effect in the -native case: CMake excludes
headers in the CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES from its
generated dependency files, meaning that a change in any library
header file will not trigger a recompile of affected source files in
the dependent CMake component. In out-of-tree builds this isn't a
problem, as cmake.bbclass deletes the *entire* ${B} directory at
configure time, but where this is not the case, the build breaks with
any change in library headers.
I haven't examined the nativesdk case. The $includedir is set off to
$SDKPATHNATIVE/usr/include, but this path is not added as a system
include dir. The same problem will apply as in the -native case, that
CMake will not generate dependencies for headers staged in the
SDKPATHNATIVE.
Was nativesdk perhaps the intended case for this commit? Is there a
better way to silence warnings in this case? Do we need to silence
library header warnings at all? Should we instead add
$SDKPATHNATIVE/usr/include as a system include dir via the
BUILDSDK_CPPFLAGS?
I examined this problem using the Unix Makefiles generator. CMake
appears to equally exclude these headers from the ninja *.o.d
dependency files, though I haven't examined it closely.
On 30/11/18 1:21 AM, Mikko Rapeli wrote:
From: Michael Ho
This resolves issues with paths being marked as system includes that
differ from /usr/include but are considered implicit by the toolchain.
This enables developers to add directories to system includes
to supress compiler compiler warnings from them.
Signed-off-by: Michael Ho
Cc: Pascal Bach
---
meta/classes/cmake.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a98..485aea6 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH
"${STAGING_DATADIR}/cmake/Modules/")
# add for non /usr/lib libdir, e.g. /usr/lib64
set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
+# add include dir to implicit includes in case it differs from
/usr/include
+list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+
EOF
}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/6] waf: python2 -> python3
Hi Ross, On 6/28/19 8:15 PM, Burton, Ross wrote: Did you just do the minimum required, or take a new copy of waf from upstream? (https://gitlab.com/ita1024/waf/) I checked the one from upstream, it is still python2. The waf is the only one which still requires python2 in oe-core. We can get rid of python2 after this patch, what's your opinion, please? // Robert Ross On Fri, 28 Jun 2019 at 13:01, Robert Yang wrote: Signed-off-by: Robert Yang --- meta/recipes-graphics/eglinfo/files/waf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/eglinfo/files/waf b/meta/recipes-graphics/eglinfo/files/waf index 04ddd9f..2c83ed4 100755 --- a/meta/recipes-graphics/eglinfo/files/waf +++ b/meta/recipes-graphics/eglinfo/files/waf @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/env python3 # encoding: latin-1 # Thomas Nagy, 2005-2018 # @@ -113,7 +113,7 @@ def unpack_wafdir(dir, src): os.remove(tmp) os.chdir(cwd) - try: dir = unicode(dir, 'mbcs') + try: dir = str(dir, 'mbcs') except: pass try: from ctypes import windll -- 2.7.4 -- ___ 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 3/5] cmake.bbclass: append includedir to implicit include dirs
This commit is having an unintended side-effect in the -native (and
probably nativesdk) case.
In the target build, $includedir is normally /usr/include,
fully-qualified. This path is already in CMake's list of implicit
include directories, and we don't include any header files from the
build PC's /usr/include in a target build in any case. This addition to
CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES has no effect.
In the -native case, the $includedir is set to STAGING_INCDIR_NATIVE,
but this path has already been added to the BUILD_CPPFLAGS as a system
include directory, so there will already be no warnings for any header
file in the STAGING_INCDIR_NATIVE.
There is a nasty side-effect in the -native case: CMake excludes headers
in the CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES from its generated
dependency files, meaning that a change in any library header file will
not trigger a recompile of affected source files in the dependent CMake
component. In out-of-tree builds this isn't a problem, as cmake.bbclass
deletes the *entire* ${B} directory at configure time, but where this is
not the case, the build breaks with any change in library headers.
I haven't examined the nativesdk case. The $includedir is set off to
$SDKPATHNATIVE/usr/include, but this path is not added as a system
include dir. The same problem will apply as in the -native case, that
CMake will not generate dependencies for headers staged in the
SDKPATHNATIVE.
Was nativesdk perhaps the intended case for this commit? Is there a
better way to silence warnings in this case? Do we need to silence
library header warnings at all? Should we instead add
$SDKPATHNATIVE/usr/include as a system include dir via the
BUILDSDK_CPPFLAGS?
I examined this problem using the Unix Makefiles generator. CMake
appears to equally exclude these headers from the ninja *.o.d dependency
files, though I haven't examined it closely.
On 30/11/18 1:21 AM, Mikko Rapeli wrote:
From: Michael Ho
This resolves issues with paths being marked as system includes that
differ from /usr/include but are considered implicit by the toolchain.
This enables developers to add directories to system includes
to supress compiler compiler warnings from them.
Signed-off-by: Michael Ho
Cc: Pascal Bach
---
meta/classes/cmake.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a98..485aea6 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH
"${STAGING_DATADIR}/cmake/Modules/")
# add for non /usr/lib libdir, e.g. /usr/lib64
set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
+# add include dir to implicit includes in case it differs from /usr/include
+list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+
EOF
}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][PATCH 2/3] devtool/standard.py: Create a copy of kernel source within work-shared if not present
If kernel source is not already downloaded i.e staging kernel dir is
empty, place a copy of the source when the user runs devtool modify
linux-yocto. This way the kernel source is available for other packages
that use it.
[YOCTO #10416]
Signed-off-by: Sai Hari Chandana Kalluri
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
scripts/lib/devtool/standard.py | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 2ac14b8..0759211 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -491,6 +491,7 @@ def _extract_source(srctree, keep_temp, devbranch, sync,
config, basepath, works
"""Extract sources of a recipe"""
import oe.recipeutils
import oe.patch
+import oe.path
pn = d.getVar('PN')
@@ -587,7 +588,7 @@ def _extract_source(srctree, keep_temp, devbranch, sync,
config, basepath, works
with open(preservestampfile, 'w') as f:
f.write(d.getVar('STAMP'))
try:
-if bb.data.inherits_class('kernel-yocto', d):
+if is_kernel_yocto:
# We need to generate the kernel config
task = 'do_configure'
else:
@@ -614,6 +615,23 @@ def _extract_source(srctree, keep_temp, devbranch, sync,
config, basepath, works
raise DevtoolError('Something went wrong with source extraction -
the devtool-source class was not active or did not function correctly:\n%s' %
str(e))
srcsubdir_rel = os.path.relpath(srcsubdir, os.path.join(tempdir,
'workdir'))
+# Check if work-shared is empty, if yes
+# find source and copy to work-shared
+if is_kernel_yocto:
+ workshareddir = d.getVar('STAGING_KERNEL_DIR')
+ staging_kerVer = get_staging_kver(workshareddir)
+ kernelVersion = d.getVar('LINUX_VERSION')
+
+ #handle dangling symbolic link in work-shared:
+ if(os.path.islink(workshareddir)):
+ os.unlink(workshareddir)
+
+ if (os.path.exists(workshareddir) and (not
os.listdir(workshareddir) or kernelVersion!=staging_kerVer)):
+ shutil.rmtree(workshareddir)
+ oe.path.copyhardlinktree(srcsubdir,workshareddir)
+ elif (not os.path.exists(workshareddir)):
+ oe.path.copyhardlinktree(srcsubdir,workshareddir)
+
tempdir_localdir = os.path.join(tempdir, 'oe-local-files')
srctree_localdir = os.path.join(srctree, 'oe-local-files')
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oeqa/recipetool: change the CMake test to use taglib
Helpful when I commit all of the changes isn't it...
On Wed, 10 Jul 2019 at 22:22, Richard Purdie
wrote:
>
> On Wed, 2019-07-10 at 13:34 +0100, Ross Burton wrote:
> > The current test builds Navit, which uses GTK+ 2. As GTK+ 2 is being
> > removed
> > from oe-core, change the test to build taglib instead.
> >
> > Signed-off-by: Ross Burton
> > ---
> > meta/lib/oeqa/selftest/cases/recipetool.py | 19 ---
> > 1 file changed, 8 insertions(+), 11 deletions(-)
> >
> > diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
> > b/meta/lib/oeqa/selftest/cases/recipetool.py
> > index e3f5c71666f..1c701a40bf0 100644
> > --- a/meta/lib/oeqa/selftest/cases/recipetool.py
> > +++ b/meta/lib/oeqa/selftest/cases/recipetool.py
> > @@ -406,22 +406,19 @@ class RecipetoolTests(RecipetoolBase):
> > self._test_recipe_contents(os.path.join(temprecipe, dirlist[0]),
> > checkvars, inherits)
> >
> > def test_recipetool_create_cmake(self):
> > -bitbake('-c packagedata gtk+')
> > -
> > -# Try adding a recipe
> > temprecipe = os.path.join(self.tempdir, 'recipe')
> > os.makedirs(temprecipe)
> > -recipefile = os.path.join(temprecipe, 'navit_0.5.0.bb')
> > -srcuri =
> > 'http://downloads.yoctoproject.org/mirror/sources/navit-0.5.0.tar.gz'
> > +recipefile = os.path.join(temprecipe, 'taglib_1.11.1.bb')
> > +srcuri = 'http://taglib.github.io/releases/taglib-1.11.1.tar.gz'
> > result = runCmd('recipetool create -o %s %s' % (temprecipe,
> > srcuri))
> > self.assertTrue(os.path.isfile(recipefile))
> > checkvars = {}
> > -checkvars['LICENSE'] = set(['Unknown', 'GPLv2', 'LGPLv2'])
> > -checkvars['SRC_URI'] =
> > 'http://downloads.yoctoproject.org/mirror/sources/navit-${PV}.tar.gz'
> > -checkvars['SRC_URI[md5sum]'] = '242f398e979a6b8c0f3c802b63435b68'
> > -checkvars['SRC_URI[sha256sum]'] =
> > '13353481d7fc01a4f64e385dda460b51496366bba0fd2cc85a89a0747910e94d'
> > -checkvars['DEPENDS'] = set(['freetype', 'zlib', 'openssl',
> > 'glib-2.0', 'virtual/libgl', 'virtual/egl', 'gtk+', 'libpng', 'libsdl',
> > 'freeglut', 'dbus-glib', 'fribidi'])
> > -inherits = ['cmake', 'python-dir', 'gettext', 'pkgconfig']
> > +checkvars['LICENSE'] = set(['LGPLv2.1', 'MPL-1.1'])
> > +checkvars['SRC_URI'] =
> > 'http://taglib.github.io/releases/taglib-${PV}.tar.gz'
> > +checkvars['SRC_URI[md5sum]'] = 'cee7be0ccfc892fa433d6c837df9522a'
> > +checkvars['SRC_URI[sha256sum]'] =
> > 'b6d1a5a610aae6ff39d93de5efd0fdc787aa9e9dc1e7026fa4c961b26563526b'
> > +checkvars['DEPENDS'] = set(['boost', 'zlib'])
> > +inherits = ['cmake']
> > self._test_recipe_contents(recipefile, checkvars, inherits)
> >
> > def test_recipetool_create_github(self):
> >
>
>
> 2019-07-10 19:33:07,067 - oe-selftest - INFO -
> ==
> 2019-07-10 19:33:07,067 - oe-selftest - INFO - FAIL:
> recipetool.RecipetoolTests.test_recipetool_create_cmake
> (subunit.RemotedTestCase)
> 2019-07-10 19:33:07,068 - oe-selftest - INFO -
> --
> 2019-07-10 19:33:07,068 - oe-selftest - INFO -
> testtools.testresult.real._StringException: Traceback (most recent call last):
> File
> "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/recipetool.py",
> line 422, in test_recipetool_create_cmake
> self._test_recipe_contents(recipefile, checkvars, inherits)
> File
> "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/devtool.py",
> line 172, in _test_recipe_contents
> self.assertEqual(value, needvalue, 'values for %s do not match' % var)
> File "/usr/lib/python3.5/unittest/case.py", line 821, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python3.5/unittest/case.py", line 1073, in assertSetEqual
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python3.5/unittest/case.py", line 666, in fail
> raise self.failureException(msg)
> AssertionError: Items in the first set but not the second:
> 'Unknown'
> Items in the second set but not the first:
> 'MPL-1.1' : values for LICENSE do not match
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/283
> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/284
>
> etc.
>
> Cheers,
>
> Richard
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oeqa/recipetool: change the CMake test to use taglib
On Wed, 2019-07-10 at 13:34 +0100, Ross Burton wrote:
> The current test builds Navit, which uses GTK+ 2. As GTK+ 2 is being removed
> from oe-core, change the test to build taglib instead.
>
> Signed-off-by: Ross Burton
> ---
> meta/lib/oeqa/selftest/cases/recipetool.py | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
> b/meta/lib/oeqa/selftest/cases/recipetool.py
> index e3f5c71666f..1c701a40bf0 100644
> --- a/meta/lib/oeqa/selftest/cases/recipetool.py
> +++ b/meta/lib/oeqa/selftest/cases/recipetool.py
> @@ -406,22 +406,19 @@ class RecipetoolTests(RecipetoolBase):
> self._test_recipe_contents(os.path.join(temprecipe, dirlist[0]),
> checkvars, inherits)
>
> def test_recipetool_create_cmake(self):
> -bitbake('-c packagedata gtk+')
> -
> -# Try adding a recipe
> temprecipe = os.path.join(self.tempdir, 'recipe')
> os.makedirs(temprecipe)
> -recipefile = os.path.join(temprecipe, 'navit_0.5.0.bb')
> -srcuri =
> 'http://downloads.yoctoproject.org/mirror/sources/navit-0.5.0.tar.gz'
> +recipefile = os.path.join(temprecipe, 'taglib_1.11.1.bb')
> +srcuri = 'http://taglib.github.io/releases/taglib-1.11.1.tar.gz'
> result = runCmd('recipetool create -o %s %s' % (temprecipe, srcuri))
> self.assertTrue(os.path.isfile(recipefile))
> checkvars = {}
> -checkvars['LICENSE'] = set(['Unknown', 'GPLv2', 'LGPLv2'])
> -checkvars['SRC_URI'] =
> 'http://downloads.yoctoproject.org/mirror/sources/navit-${PV}.tar.gz'
> -checkvars['SRC_URI[md5sum]'] = '242f398e979a6b8c0f3c802b63435b68'
> -checkvars['SRC_URI[sha256sum]'] =
> '13353481d7fc01a4f64e385dda460b51496366bba0fd2cc85a89a0747910e94d'
> -checkvars['DEPENDS'] = set(['freetype', 'zlib', 'openssl',
> 'glib-2.0', 'virtual/libgl', 'virtual/egl', 'gtk+', 'libpng', 'libsdl',
> 'freeglut', 'dbus-glib', 'fribidi'])
> -inherits = ['cmake', 'python-dir', 'gettext', 'pkgconfig']
> +checkvars['LICENSE'] = set(['LGPLv2.1', 'MPL-1.1'])
> +checkvars['SRC_URI'] =
> 'http://taglib.github.io/releases/taglib-${PV}.tar.gz'
> +checkvars['SRC_URI[md5sum]'] = 'cee7be0ccfc892fa433d6c837df9522a'
> +checkvars['SRC_URI[sha256sum]'] =
> 'b6d1a5a610aae6ff39d93de5efd0fdc787aa9e9dc1e7026fa4c961b26563526b'
> +checkvars['DEPENDS'] = set(['boost', 'zlib'])
> +inherits = ['cmake']
> self._test_recipe_contents(recipefile, checkvars, inherits)
>
> def test_recipetool_create_github(self):
>
2019-07-10 19:33:07,067 - oe-selftest - INFO -
==
2019-07-10 19:33:07,067 - oe-selftest - INFO - FAIL:
recipetool.RecipetoolTests.test_recipetool_create_cmake
(subunit.RemotedTestCase)
2019-07-10 19:33:07,068 - oe-selftest - INFO -
--
2019-07-10 19:33:07,068 - oe-selftest - INFO -
testtools.testresult.real._StringException: Traceback (most recent call last):
File
"/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/recipetool.py",
line 422, in test_recipetool_create_cmake
self._test_recipe_contents(recipefile, checkvars, inherits)
File
"/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/devtool.py",
line 172, in _test_recipe_contents
self.assertEqual(value, needvalue, 'values for %s do not match' % var)
File "/usr/lib/python3.5/unittest/case.py", line 821, in assertEqual
assertion_func(first, second, msg=msg)
File "/usr/lib/python3.5/unittest/case.py", line 1073, in assertSetEqual
self.fail(self._formatMessage(msg, standardMsg))
File "/usr/lib/python3.5/unittest/case.py", line 666, in fail
raise self.failureException(msg)
AssertionError: Items in the first set but not the second:
'Unknown'
Items in the second set but not the first:
'MPL-1.1' : values for LICENSE do not match
https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/283
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/284
etc.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][PATCH 3/3] devtool: provide support for devtool menuconfig command
All packages that support the menuconfig task will be able to run
devtool menuconfig command. This would allow the user to modify the
current configure options and create a config fragment which can be
added to a recipe using devtool finish.
1. The patch checks if devtool menuconfig command is called for a valid
package.
2. It checks for oe-local-files dir within source and creates one if
needed, this directory is needed to store the final generated config
fragment so that devtool finish can update the recipe.
3. Menuconfig command is called for users to make necessary changes.
After saving the changes, diffconfig command is run to generate the
fragment.
Syntax:
devtool menuconfig
Ex: devtool menuconfig linux-yocto
The config fragment is saved as devtool-fragment.cfg within
oe-local-files dir.
Ex:
/sources/linux-yocto/oe-local-files/devtool-fragment.cfg
Run devtool finish to update the recipe by appending the config fragment
to SRC_URI and place a copy of the fragment within the layer where the
recipe resides.
Ex: devtool finish linux-yocto meta
[YOCTO #10416]
Signed-off-by: Sai Hari Chandana Kalluri
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
scripts/lib/devtool/menuconfig.py | 79 +++
scripts/lib/devtool/standard.py | 5 +++
2 files changed, 84 insertions(+)
create mode 100644 scripts/lib/devtool/menuconfig.py
diff --git a/scripts/lib/devtool/menuconfig.py
b/scripts/lib/devtool/menuconfig.py
new file mode 100644
index 000..20d919b
--- /dev/null
+++ b/scripts/lib/devtool/menuconfig.py
@@ -0,0 +1,79 @@
+# OpenEmbedded Development tool - menuconfig command plugin
+#
+# Copyright (C) 2018 Xilinx
+# Written by: Chandana Kalluri
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+"""Devtool menuconfig plugin"""
+
+import os
+import bb
+import logging
+import argparse
+import re
+import glob
+from devtool import setup_tinfoil, parse_recipe, DevtoolError, standard,
exec_build_env_command
+from devtool import check_workspace_recipe
+logger = logging.getLogger('devtool')
+
+def menuconfig(args, config, basepath, workspace):
+"""Entry point for the devtool 'menuconfig' subcommand"""
+
+rd = ""
+kconfigpath = ""
+pn_src = ""
+localfilesdir = ""
+workspace_dir = ""
+tinfoil = setup_tinfoil(basepath=basepath)
+try:
+ rd = parse_recipe(config, tinfoil, args.component, appends=True,
filter_workspace=False)
+ if not rd:
+ return 1
+
+ check_workspace_recipe(workspace, args.component)
+ pn = rd.getVar('PN', True)
+
+ if not rd.getVarFlag('do_menuconfig','task'):
+ raise DevtoolError("This recipe does not support menuconfig option")
+
+ workspace_dir = os.path.join(config.workspace_path,'sources')
+ kconfigpath = rd.getVar('B')
+ pn_src = os.path.join(workspace_dir,pn)
+
+ #add check to see if oe_local_files exists or not
+ localfilesdir = os.path.join(pn_src,'oe-local-files')
+ if not os.path.exists(localfilesdir):
+ bb.utils.mkdirhier(localfilesdir)
+ #Add gitignore to ensure source tree is clean
+ gitignorefile = os.path.join(localfilesdir,'.gitignore')
+ with open(gitignorefile, 'w') as f:
+ f.write('# Ignore local files, by default. Remove this file
if you want to commit the directory to Git\n')
+ f.write('*\n')
+
+finally:
+ tinfoil.shutdown()
+
+logger.info('Launching menuconfig')
+exec_build_env_command(config.init_path, basepath, 'bitbake -c menuconfig
%s' % pn, watch=True)
+fragment = os.path.join(localfilesdir, 'devtool-fragment.cfg')
+res = standard._create_kconfig_diff(pn_src,rd,fragment)
+
+return 0
+
+def register_commands(subparsers, context):
+"""register devtool subcommands from this plugin"""
+parser_menuconfig = subparsers.add_parser('menuconfig',help='Alter
build-time configuration for a recipe', description='Launches the make
menuconfig command (for recipes where do_menuconfig is available), allowing
users to make changes to the build-time configuration. Creates a config
fragment corresponding to changes made.', group='advanced')
+parser_menuconfig.add_argument('component', help='compenent to alter
config')
+
Re: [OE-core] [PATCH 6/9] linux-yocto-dev: bump to v5.2-rc
On 10/07/2019 16.28, Richard Purdie wrote: On Wed, 2019-07-10 at 15:27 +0100, richard.pur...@linuxfoundation.org wrote: On Wed, 2019-07-10 at 10:21 -0400, Bruce Ashfield wrote: On Wed, Jul 10, 2019 at 10:15 AM Martin Hundebøll < mar...@geanix.com> Nope, I haven't seen that. But then again, all my machines have realpath available. As you hinted, building all of coreutils as a dependency for the kernel is a bit heavy. We could make realpath a host requirement, or otherwise, split out realpath (but you'd still need to build coreutils, so that really doesn't help). I'd lean towards just making it a host requirement .. but I'm sure Richard can advise better than me on the pro's and con's of the options. realpath is in the standard HOSTTOOLS in bitbake.conf so its already required? http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?id=12e1a0de18fc05e68be8e6f1688c1499e37b076b Now I see; I am building on thud... Armin, can you backport commit 12e1a0de18fc05e68be8e6f1688c1499e37b076b to active branches? Thanks, Martin -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/9] linux-yocto-dev: bump to v5.2-rc
On Wed, Jul 10, 2019 at 10:28 AM Richard Purdie wrote: > > On Wed, 2019-07-10 at 15:27 +0100, richard.pur...@linuxfoundation.org > wrote: > > On Wed, 2019-07-10 at 10:21 -0400, Bruce Ashfield wrote: > > > On Wed, Jul 10, 2019 at 10:15 AM Martin Hundebøll < > > > mar...@geanix.com> > > > > > > > > > Nope, I haven't seen that. But then again, all my machines have > > > realpath available. > > > > > > As you hinted, building all of coreutils as a dependency for the > > > kernel is a bit heavy. We could make > > > realpath a host requirement, or otherwise, split out realpath (but > > > you'd still need to build coreutils, so > > > that really doesn't help). > > > > > > I'd lean towards just making it a host requirement .. but I'm sure > > > Richard can advise better than me > > > on the pro's and con's of the options. > > > > realpath is in the standard HOSTTOOLS in bitbake.conf so its already > > required? > > http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?id=12e1a0de18fc05e68be8e6f1688c1499e37b076b > > and yes, I'll have words with ross about commit messages :) As the guy who can't spell scsi in commit messages, I shall throw no stones :D It looks like we are covered, and I just confirmed that I can build and boot the full 5.2 release. Bruce > > Cheers, > > Richard > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] cve-update-db: New recipe to update CVE database
Hi Pierre, I found that the hash function is causing collisions in the generated database such that some CVEs are being overwritten because of the UNIQUE constraint on the HASH column. For example, CVE-2018-1000873 has the same hash of 623198722 as CVE-2018-18338. This results in one of the two CVEs not appearing in the database. -- Kevin Weng -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/9] linux-yocto-dev: bump to v5.2-rc
On Wed, 2019-07-10 at 15:27 +0100, richard.pur...@linuxfoundation.org wrote: > On Wed, 2019-07-10 at 10:21 -0400, Bruce Ashfield wrote: > > On Wed, Jul 10, 2019 at 10:15 AM Martin Hundebøll < > > mar...@geanix.com> > > > > > > Nope, I haven't seen that. But then again, all my machines have > > realpath available. > > > > As you hinted, building all of coreutils as a dependency for the > > kernel is a bit heavy. We could make > > realpath a host requirement, or otherwise, split out realpath (but > > you'd still need to build coreutils, so > > that really doesn't help). > > > > I'd lean towards just making it a host requirement .. but I'm sure > > Richard can advise better than me > > on the pro's and con's of the options. > > realpath is in the standard HOSTTOOLS in bitbake.conf so its already > required? http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?id=12e1a0de18fc05e68be8e6f1688c1499e37b076b and yes, I'll have words with ross about commit messages :) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/9] linux-yocto-dev: bump to v5.2-rc
On Wed, 2019-07-10 at 10:21 -0400, Bruce Ashfield wrote:
> On Wed, Jul 10, 2019 at 10:15 AM Martin Hundebøll
> wrote:
> > Hi Bruce,
> >
> > On 30/05/2019 14.44, bruce.ashfi...@gmail.com wrote:
> > > From: Bruce Ashfield
> > >
> > > Signed-off-by: Bruce Ashfield
> > > ---
> > > meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > index ae8c343008..3a055c12ad 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > @@ -30,7 +30,7 @@ SRC_URI = "git://git.yoctoproject.org/linux-
> > > yocto-dev.git;branch=${KBRANCH};name
> > > SRCREV_machine ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_
> > > virtual/kernel", "linux-yocto-dev", "${AUTOREV}",
> > > "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
> > > SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_vir
> > > tual/kernel", "linux-yocto-dev", "${AUTOREV}",
> > > "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
> > >
> > > -LINUX_VERSION ?= "5.0-rc+"
> > > +LINUX_VERSION ?= "5.2-rc+"
> > > LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
> > > PV = "${LINUX_VERSION}+git${SRCPV}"
> >
> > My own kernel recipe (more or less mainline) failed to build when I
> > bumped to v5.2. It fails to generate the out-of-tree Makefile due
> > to a
> > missing dependency on `realpath`[1].
> >
> > The quick-fix is to add coreutils-native to DEPENDS, but I am not
> > sure
> > if this is what we want.
> >
> > Have you seen the same?
>
> Nope, I haven't seen that. But then again, all my machines have
> realpath available.
>
> As you hinted, building all of coreutils as a dependency for the
> kernel is a bit heavy. We could make
> realpath a host requirement, or otherwise, split out realpath (but
> you'd still need to build coreutils, so
> that really doesn't help).
>
> I'd lean towards just making it a host requirement .. but I'm sure
> Richard can advise better than me
> on the pro's and con's of the options.
realpath is in the standard HOSTTOOLS in bitbake.conf so its already
required?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/9] linux-yocto-dev: bump to v5.2-rc
On Wed, Jul 10, 2019 at 10:15 AM Martin Hundebøll wrote:
>
> Hi Bruce,
>
> On 30/05/2019 14.44, bruce.ashfi...@gmail.com wrote:
> > From: Bruce Ashfield
> >
> > Signed-off-by: Bruce Ashfield
> > ---
> > meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > index ae8c343008..3a055c12ad 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > @@ -30,7 +30,7 @@ SRC_URI =
> > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
> > SRCREV_machine ?=
> > '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
> > "linux-yocto-dev", "${AUTOREV}",
> > "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
> > SRCREV_meta ?=
> > '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
> > "linux-yocto-dev", "${AUTOREV}",
> > "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
> >
> > -LINUX_VERSION ?= "5.0-rc+"
> > +LINUX_VERSION ?= "5.2-rc+"
> > LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
> > PV = "${LINUX_VERSION}+git${SRCPV}"
>
> My own kernel recipe (more or less mainline) failed to build when I
> bumped to v5.2. It fails to generate the out-of-tree Makefile due to a
> missing dependency on `realpath`[1].
>
> The quick-fix is to add coreutils-native to DEPENDS, but I am not sure
> if this is what we want.
>
> Have you seen the same?
Nope, I haven't seen that. But then again, all my machines have
realpath available.
As you hinted, building all of coreutils as a dependency for the
kernel is a bit heavy. We could make
realpath a host requirement, or otherwise, split out realpath (but
you'd still need to build coreutils, so
that really doesn't help).
I'd lean towards just making it a host requirement .. but I'm sure
Richard can advise better than me
on the pro's and con's of the options.
Bruce
>
> // Martin
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48b5ffd1268788afb01525e71e864e901e9aa070
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/9] linux-yocto-dev: bump to v5.2-rc
Hi Bruce,
On 30/05/2019 14.44, bruce.ashfi...@gmail.com wrote:
From: Bruce Ashfield
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index ae8c343008..3a055c12ad 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -30,7 +30,7 @@ SRC_URI =
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
SRCREV_machine ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-yocto-dev",
"${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
-LINUX_VERSION ?= "5.0-rc+"
+LINUX_VERSION ?= "5.2-rc+"
LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
PV = "${LINUX_VERSION}+git${SRCPV}"
My own kernel recipe (more or less mainline) failed to build when I
bumped to v5.2. It fails to generate the out-of-tree Makefile due to a
missing dependency on `realpath`[1].
The quick-fix is to add coreutils-native to DEPENDS, but I am not sure
if this is what we want.
Have you seen the same?
// Martin
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48b5ffd1268788afb01525e71e864e901e9aa070
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] config warning from linux-yocto 4.19
On Wed, Jul 10, 2019 at 9:37 AM wrote: > > On Wed, 2019-07-10 at 08:57 -0400, Bruce Ashfield wrote: > > That should have been covered in this patch I sent: > > > > commit 95e9df0b5cb5179271c78499dc60c3c0df0a5622 > > Author: Bruce Ashfield > > Date: Fri Jul 5 11:15:37 2019 -0400 > > > > linux-yocto/4.19: update to 4.19.57 and -rt22 > > > > Updating the linux-yocto 4.19 recipe to the latest -stable and > > -rt > > releases. > > > > We also integrate a configuration change to support ptests on > > scsci > > targets: > > > > scsi-debug: include core scsi support for standalone inclusion > > > > The -stable changes comprise the following commits: > > --- > > > > Is that applied and yet we are still seeing the warning ? > > No, I think I've missed some patches, which would explain a few things. > I'll go digging I relayed them through gmail .. which normally works, but it shows up in my mail as non-obviously gone to the list when I both relay via gmail and read it in gmail. So let me know if they have in fact gone missing and I'll resend. Bruce > > Cheers, > > Richard > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] config warning from linux-yocto 4.19
On Wed, 2019-07-10 at 08:57 -0400, Bruce Ashfield wrote: > That should have been covered in this patch I sent: > > commit 95e9df0b5cb5179271c78499dc60c3c0df0a5622 > Author: Bruce Ashfield > Date: Fri Jul 5 11:15:37 2019 -0400 > > linux-yocto/4.19: update to 4.19.57 and -rt22 > > Updating the linux-yocto 4.19 recipe to the latest -stable and > -rt > releases. > > We also integrate a configuration change to support ptests on > scsci > targets: > > scsi-debug: include core scsi support for standalone inclusion > > The -stable changes comprise the following commits: > --- > > Is that applied and yet we are still seeing the warning ? No, I think I've missed some patches, which would explain a few things. I'll go digging Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Provide tasks to generate default U-Boot environment(s) images
On 7/9/19 7:20 AM, Lukasz Majewski wrote:
> This change provides tasks to generate default U-Boot environment images
> from built U-Boot (via. get_default_envs.sh script).
>
> Those images then can be used to generate wic images (with e.g. eMMC layout).
> With such approach the end user doesn't see the "CRC environment" error
> after the first boot.
>
> Moreover, those are built per MACHINE (as u-boot itself is) so then could
> be used in SWUpdate scenarios with single tar'ed archive with multiple
> MACHINE specific *.swu images.
I like this idea.
>
> It is also possible to adjust the *_ENVS_* variables in machine specific
> conf file.
Can you give an example on how that is done or what it would look like?
I have been using this class I created a while back to do just that
https://github.com/akuster/meta-odroid/blob/master/classes/uboot-boot-scr.bbclass
- armin
> Test:
> Newest master-next for poky repo - SHA1:
> eb5b0a0b5e53a6e55a09e66489d3f24d0c6232ee
> MACHINE = "beaglebone-yocto" in local.conf
> bitbake virtual/bootloader
>
>
> As a result following links are available in deploy directory:
> u-boot-env.img{_r}.
>
> Signed-off-by: Lukasz Majewski
> ---
> meta/recipes-bsp/u-boot/u-boot.inc | 41
> ++
> 1 file changed, 41 insertions(+)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 9a754fd09b..e0ccf1ce1f 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -331,3 +331,44 @@ do_deploy () {
> }
>
> addtask deploy before do_build after do_compile
> +
> +# Extract default envs from build U-Boot
> +DEFAULT_UBOOT_ENVS_FILE ?= "u-boot-env"
> +DEFAULT_ENVS ?= "${DEFAULT_UBOOT_ENVS_FILE}.txt"
> +UBOOT_ENVS_DEFAULT ?= "${DEFAULT_UBOOT_ENVS_FILE}-${MACHINE}-${PV}-${PR}.img"
> +UBOOT_ENVS_SIZE ?= "65536"
> +
> +# Generate default environment
> +do_gen_default_envs[doc] = "Generate image with default U-Boot
> environment(s)"
> +do_gen_default_envs () {
> +${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
> +
> +# Generate env image
> +${B}/tools/mkenvimage -s ${UBOOT_ENVS_SIZE} -o
> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
> +
> +# Generate redundant env image
> +${B}/tools/mkenvimage -r -s ${UBOOT_ENVS_SIZE} -o
> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
> +
> +rm ${B}/${DEFAULT_ENVS}
> +}
> +
> +addtask gen_default_envs before do_deploy after do_compile
> +
> +# Deploy default environment
> +do_deploy_default_envs[doc] = "Copy images with default U-Boot environment
> to deployment directory"
> +do_deploy_default_envs () {
> +
> + install -d ${DEPLOYDIR}
> +
> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
> +
> + cd ${DEPLOYDIR}
> + ln -sf ${UBOOT_ENVS_DEFAULT} ${DEFAULT_UBOOT_ENVS_FILE}.img
> + ln -sf ${UBOOT_ENVS_DEFAULT}_r ${DEFAULT_UBOOT_ENVS_FILE}.img_r
> +
> + rm ${B}/${UBOOT_ENVS_DEFAULT}
> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> +}
> +
> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] config warning from linux-yocto 4.19
That should have been covered in this patch I sent: commit 95e9df0b5cb5179271c78499dc60c3c0df0a5622 Author: Bruce Ashfield Date: Fri Jul 5 11:15:37 2019 -0400 linux-yocto/4.19: update to 4.19.57 and -rt22 Updating the linux-yocto 4.19 recipe to the latest -stable and -rt releases. We also integrate a configuration change to support ptests on scsci targets: scsi-debug: include core scsi support for standalone inclusion The -stable changes comprise the following commits: --- Is that applied and yet we are still seeing the warning ? Bruce On Wed, Jul 10, 2019 at 4:47 AM Richard Purdie wrote: > > Hi Bruce, > > I think/hope this is just a kernel config srcrev update but could you fix: > > """ > WARNING: linux-yocto-4.19.44+gitAUTOINC+ad235db461_c12bc1a098-r0 > do_kernel_configcheck: [kernel config]: specified values did not make it into > the kernel's final configuration: > > -- CONFIG_SCSI_DEBUG - > Config: CONFIG_SCSI_DEBUG > From: > /home/pokybuild/yocto-worker/qemuarm-lsb/build/build/tmp/work-shared/qemuarm/kernel-source/.kernel-meta/configs/v4.19/standard/qemuarma15/features/scsi/scsi-debug.cfg > Requested value: CONFIG_SCSI_DEBUG=m > Actual value: > > No reference to SCSI_DEBUG found > """ > > please? :) We're fairly warning free on the autobuilder now so this one > sticks out badly! > > https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/804 > > (its qemuarm with poky-lsb) > > Cheers, > > Richard > > > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for systemd: backport patch to fix sysctl warning on boot
On Wed, 2019-07-10 at 12:31 +, Patchwork wrote: > == Series Details == > > Series: systemd: backport patch to fix sysctl warning on boot > Revision: 1 > URL : https://patchwork.openembedded.org/series/18605/ > State : failure > > == Summary == > > > Thank you for submitting this patch series to OpenEmbedded Core. This > is > an automated response. Several tests have been executed on the > proposed > series by patchtest resulting in the following failures: > > > > * Issue Series cannot be parsed correctly due to > malformed diff lines [test_mbox_format] > Suggested fixCreate the series again using git-format-patch and > ensure it can be applied using git am > Diff lineHunk is shorter than expected > > * Issue Series does not apply on top of target branch > [test_series_merge_on_head] > Suggested fixRebase your series on top of targeted branch > Targeted branch master (currently at 4cbb7392c7) I'm not sure what is going on here, the patch applies fine for me. Is it possible that the patchtest stumbles over unicode characters in the added patch file? I don't see how that could be avoided, as the patch touches a line where an emoji was used in a comment... Kind regards, Matthias > > > > If you believe any of these test results are incorrect, please reply > to the > mailing list (openembedded-core@lists.openembedded.org) raising your > concerns. > Otherwise we would appreciate you correcting the issues and > submitting a new > version of the patchset if applicable. Please ensure you > add/increment the > version number when sending the new version (i.e. [PATCH] -> [PATCH > v2] -> > [PATCH v3] -> ...). > > --- > Guidelines: > https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest > Test suite: > http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/recipetool: change the CMake test to use taglib
The current test builds Navit, which uses GTK+ 2. As GTK+ 2 is being removed
from oe-core, change the test to build taglib instead.
Signed-off-by: Ross Burton
---
meta/lib/oeqa/selftest/cases/recipetool.py | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
b/meta/lib/oeqa/selftest/cases/recipetool.py
index e3f5c71666f..1c701a40bf0 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -406,22 +406,19 @@ class RecipetoolTests(RecipetoolBase):
self._test_recipe_contents(os.path.join(temprecipe, dirlist[0]),
checkvars, inherits)
def test_recipetool_create_cmake(self):
-bitbake('-c packagedata gtk+')
-
-# Try adding a recipe
temprecipe = os.path.join(self.tempdir, 'recipe')
os.makedirs(temprecipe)
-recipefile = os.path.join(temprecipe, 'navit_0.5.0.bb')
-srcuri =
'http://downloads.yoctoproject.org/mirror/sources/navit-0.5.0.tar.gz'
+recipefile = os.path.join(temprecipe, 'taglib_1.11.1.bb')
+srcuri = 'http://taglib.github.io/releases/taglib-1.11.1.tar.gz'
result = runCmd('recipetool create -o %s %s' % (temprecipe, srcuri))
self.assertTrue(os.path.isfile(recipefile))
checkvars = {}
-checkvars['LICENSE'] = set(['Unknown', 'GPLv2', 'LGPLv2'])
-checkvars['SRC_URI'] =
'http://downloads.yoctoproject.org/mirror/sources/navit-${PV}.tar.gz'
-checkvars['SRC_URI[md5sum]'] = '242f398e979a6b8c0f3c802b63435b68'
-checkvars['SRC_URI[sha256sum]'] =
'13353481d7fc01a4f64e385dda460b51496366bba0fd2cc85a89a0747910e94d'
-checkvars['DEPENDS'] = set(['freetype', 'zlib', 'openssl', 'glib-2.0',
'virtual/libgl', 'virtual/egl', 'gtk+', 'libpng', 'libsdl', 'freeglut',
'dbus-glib', 'fribidi'])
-inherits = ['cmake', 'python-dir', 'gettext', 'pkgconfig']
+checkvars['LICENSE'] = set(['LGPLv2.1', 'MPL-1.1'])
+checkvars['SRC_URI'] =
'http://taglib.github.io/releases/taglib-${PV}.tar.gz'
+checkvars['SRC_URI[md5sum]'] = 'cee7be0ccfc892fa433d6c837df9522a'
+checkvars['SRC_URI[sha256sum]'] =
'b6d1a5a610aae6ff39d93de5efd0fdc787aa9e9dc1e7026fa4c961b26563526b'
+checkvars['DEPENDS'] = set(['boost', 'zlib'])
+inherits = ['cmake']
self._test_recipe_contents(recipefile, checkvars, inherits)
def test_recipetool_create_github(self):
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for systemd: backport patch to fix sysctl warning on boot (rev2)
== Series Details == Series: systemd: backport patch to fix sysctl warning on boot (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/18605/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series cannot be parsed correctly due to malformed diff lines [test_mbox_format] Suggested fixCreate the series again using git-format-patch and ensure it can be applied using git am Diff lineHunk is shorter than expected * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch warrior (currently at 886deb4d09) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for systemd: backport patch to fix sysctl warning on boot
== Series Details == Series: systemd: backport patch to fix sysctl warning on boot Revision: 1 URL : https://patchwork.openembedded.org/series/18605/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series cannot be parsed correctly due to malformed diff lines [test_mbox_format] Suggested fixCreate the series again using git-format-patch and ensure it can be applied using git am Diff lineHunk is shorter than expected * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 4cbb7392c7) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH warrior] systemd: backport patch to fix sysctl warning on boot
Due to improved validation of sysctl settings in recent kernels (5.2+, but
also stable kernels like 4.19.53), systemd will log an error message like
systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
during boot. Backport the bugfix from the systemd master.
Signed-off-by: Matthias Schiffer
---
...-max-sysctl-to-LONG_MAX-rather-than-.patch | 39 +++
meta/recipes-core/systemd/systemd_241.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
diff --git
a/meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
b/meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
new file mode 100644
index 00..ff64f58c9c
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
@@ -0,0 +1,39 @@
+From 6e2f78948403a4cce45b9e34311c9577c624f066 Mon Sep 17 00:00:00 2001
+From: Lennart Poettering
+Date: Mon, 17 Jun 2019 10:51:25 +0200
+Subject: [PATCH] core: set fs.file-max sysctl to LONG_MAX rather than
+ ULONG_MAX
+
+Since kernel 5.2 the kernel thankfully returns proper errors when we
+write a value out of range to the sysctl. Which however breaks writing
+ULONG_MAX to request the maximum value. Hence let's write the new
+maximum value instead, LONG_MAX.
+
+/cc @brauner
+
+Fixes: #12803
+
+Upstream-Status: Backport
+
+Signed-off-by: Matthias Schiffer
+---
+ src/core/main.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/core/main.c b/src/core/main.c
+index b33ea1b5b5..e7f51815f0 100644
+--- a/src/core/main.c
b/src/core/main.c
+@@ -1245,9 +1245,9 @@ static void bump_file_max_and_nr_open(void) {
+ #endif
+
+ #if BUMP_PROC_SYS_FS_FILE_MAX
+-/* I so wanted to use STRINGIFY(ULONG_MAX) here, but alas we can't as
glibc/gcc define that as
+- * "(0x7fffL * 2UL + 1UL)". Seriously. */
+-if (asprintf(, "%lu\n", ULONG_MAX) < 0) {
++/* The maximum the kernel allows for this since 5.2 is LONG_MAX, use
that. (Previously thing where
++ * different but the operation would fail silently.) */
++if (asprintf(, "%li\n", LONG_MAX) < 0) {
+ log_oom();
+ return;
+ }
diff --git a/meta/recipes-core/systemd/systemd_241.bb
b/meta/recipes-core/systemd/systemd_241.bb
index eb3242d624..17d3bc1864 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -24,6 +24,7 @@ SRC_URI += "file://touchscreen.rules \
file://0005-rules-watch-metadata-changes-in-ide-devices.patch \
file://0001-meson-declare-version.h-as-dep-for-various-targets-t.patch \
file://0001-meson-declare-version.h-as-dependency-for-systemd.patch
\
+
file://0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch \
"
# patches needed by musl
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: backport patch to fix sysctl warning on boot
Due to improved validation of sysctl settings in recent kernels (5.2+, but
also stable kernels like 4.19.53), systemd will log an error message like
systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
during boot. Backport the bugfix from the systemd master.
Signed-off-by: Matthias Schiffer
---
...-max-sysctl-to-LONG_MAX-rather-than-.patch | 39 +++
meta/recipes-core/systemd/systemd_242.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
diff --git
a/meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
b/meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
new file mode 100644
index 00..ff64f58c9c
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch
@@ -0,0 +1,39 @@
+From 6e2f78948403a4cce45b9e34311c9577c624f066 Mon Sep 17 00:00:00 2001
+From: Lennart Poettering
+Date: Mon, 17 Jun 2019 10:51:25 +0200
+Subject: [PATCH] core: set fs.file-max sysctl to LONG_MAX rather than
+ ULONG_MAX
+
+Since kernel 5.2 the kernel thankfully returns proper errors when we
+write a value out of range to the sysctl. Which however breaks writing
+ULONG_MAX to request the maximum value. Hence let's write the new
+maximum value instead, LONG_MAX.
+
+/cc @brauner
+
+Fixes: #12803
+
+Upstream-Status: Backport
+
+Signed-off-by: Matthias Schiffer
+---
+ src/core/main.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/core/main.c b/src/core/main.c
+index b33ea1b5b5..e7f51815f0 100644
+--- a/src/core/main.c
b/src/core/main.c
+@@ -1245,9 +1245,9 @@ static void bump_file_max_and_nr_open(void) {
+ #endif
+
+ #if BUMP_PROC_SYS_FS_FILE_MAX
+-/* I so wanted to use STRINGIFY(ULONG_MAX) here, but alas we can't as
glibc/gcc define that as
+- * "(0x7fffL * 2UL + 1UL)". Seriously. */
+-if (asprintf(, "%lu\n", ULONG_MAX) < 0) {
++/* The maximum the kernel allows for this since 5.2 is LONG_MAX, use
that. (Previously thing where
++ * different but the operation would fail silently.) */
++if (asprintf(, "%li\n", LONG_MAX) < 0) {
+ log_oom();
+ return;
+ }
diff --git a/meta/recipes-core/systemd/systemd_242.bb
b/meta/recipes-core/systemd/systemd_242.bb
index 29f64b995a..ca083ad376 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -25,6 +25,7 @@ SRC_URI += "file://touchscreen.rules \
file://0006-network-remove-redunant-link-name-in-message.patch \
file://99-default.preset \
file://0001-resolved-Fix-incorrect-use-of-OpenSSL-BUF_MEM.patch \
+
file://0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch \
"
# patches needed by musl
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] cve-update-db: New recipe to update CVE database
Hi Kevin, > I found that the hash function is causing collisions in the generated > database such that some CVEs are being overwritten because of the UNIQUE > constraint on the HASH column. For example, CVE-2018-1000873 has the same > hash of 623198722 as CVE-2018-18338. This results in one of the two CVEs not > appearing in the database. This is problematic. I kept using djb2 hash function, because it was the one used in the previous cve-check-tool and it was fast. But it might not be the right hash function to use. Do you have a better hash function in mind ? I can also drop hash function, remove everything from the database and recreate all entries at each update but it will increase database update time. I don't have the same hash as you for CVE-2018-1000873 and CVE-2018-18338, do you use my latest patches from master ? I did several changes recently. Pierre Le Magourou -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Problems with sstate-cache in Artifactory
Hi Chris, I tried uploading sstate-cache again in Artifactory but this time used jfrog-cli (https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory) instead of curl and now it is working fine. regards Ankur On Wed, Jul 10, 2019 at 1:39 PM Ankur Tyagi wrote: > > On Wed, Jul 10, 2019 at 2:28 AM chris.lapla...@agilent.com > wrote: > > > > > DEBUG: For url file://5c/sstate:u-boot-ti-staging:wsl-linux- > > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > > returning > > > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti- > > > staging%3Awsl-linux- > > > gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz; > > > downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux- > > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus() urlopen failed: HTTP Error 404: Not Found > > > > Is this mapping correct? Does using curl to download > > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti-staging%3Awsl-linux-gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz;downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > work? > > > > Yes, curl/wget can download it. What wrong do you suspect here? > > Thanks > Ankur > > > Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Provide tasks to generate default U-Boot environment(s) images
Hi Richard,
> On Tue, 2019-07-09 at 16:20 +0200, Lukasz Majewski wrote:
> > This change provides tasks to generate default U-Boot environment
> > images from built U-Boot (via. get_default_envs.sh script).
> >
> > Those images then can be used to generate wic images (with e.g.
> > eMMC layout). With such approach the end user doesn't see the "CRC
> > environment" error after the first boot.
> >
> > Moreover, those are built per MACHINE (as u-boot itself is) so then
> > could be used in SWUpdate scenarios with single tar'ed archive with
> > multiple MACHINE specific *.swu images.
> >
> > It is also possible to adjust the *_ENVS_* variables in machine
> > specific conf file.
> >
> > Test:
> > Newest master-next for poky repo - SHA1:
> > eb5b0a0b5e53a6e55a09e66489d3f24d0c6232ee MACHINE =
> > "beaglebone-yocto" in local.conf bitbake virtual/bootloader
> >
> >
> > As a result following links are available in deploy directory:
> > u-boot-env.img{_r}.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > meta/recipes-bsp/u-boot/u-boot.inc | 41
> > ++ 1 file changed, 41
> > insertions(+)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> > b/meta/recipes-bsp/u-boot/u-boot.inc index 9a754fd09b..e0ccf1ce1f
> > 100644 --- a/meta/recipes-bsp/u-boot/u-boot.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> > @@ -331,3 +331,44 @@ do_deploy () {
> > }
> >
> > addtask deploy before do_build after do_compile
> > +
> > +# Extract default envs from build U-Boot
> > +DEFAULT_UBOOT_ENVS_FILE ?= "u-boot-env"
> > +DEFAULT_ENVS ?= "${DEFAULT_UBOOT_ENVS_FILE}.txt"
> > +UBOOT_ENVS_DEFAULT ?=
> > "${DEFAULT_UBOOT_ENVS_FILE}-${MACHINE}-${PV}-${PR}.img"
> > +UBOOT_ENVS_SIZE ?= "65536" +
> > +# Generate default environment
> > +do_gen_default_envs[doc] = "Generate image with default U-Boot
> > environment(s)" +do_gen_default_envs () {
> > +${B}/source/scripts/get_default_envs.sh ${B} >
> > ${B}/${DEFAULT_ENVS} +
> > +# Generate env image
> > +${B}/tools/mkenvimage -s ${UBOOT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS} +
> > +# Generate redundant env image
> > +${B}/tools/mkenvimage -r -s ${UBOOT_ENVS_SIZE} -o
> > ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS} +
> > +rm ${B}/${DEFAULT_ENVS}
> > +}
> > +
> > +addtask gen_default_envs before do_deploy after do_compile
> > +
> > +# Deploy default environment
> > +do_deploy_default_envs[doc] = "Copy images with default U-Boot
> > environment to deployment directory" +do_deploy_default_envs () {
> > +
> > + install -d ${DEPLOYDIR}
> > +
> > + install ${B}/${UBOOT_ENVS_DEFAULT}
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> > + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> > ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r +
> > + cd ${DEPLOYDIR}
> > + ln -sf ${UBOOT_ENVS_DEFAULT} ${DEFAULT_UBOOT_ENVS_FILE}.img
> > + ln -sf ${UBOOT_ENVS_DEFAULT}_r
> > ${DEFAULT_UBOOT_ENVS_FILE}.img_r +
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}
> > + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> > +}
> > +
> > +addtask deploy_default_envs before do_deploy after
> > do_gen_default_envs
>
> I'm not sure this second function/task is right.
>
> DEPLOYDIR is really "owned" by the do_deploy function. As such, if you
> rerun the deploy task, it should be recreated with the right content.
>
> By default I appreciate that deploy.bbclass doesn't wipe out the
> directory but it probably should to make it clear what the
> expectations are here.
>
> I don't think it would cause a real problem right now, until files
> changed names or something in one of these tasks, then you'd end up
> with files you didn't expect since nothing ever cleans this directory.
>
> Is there a reason we can't make this part of do_deploy and clean the
> directory at the start of do_deploy?
The only reason was to have more readable code - as it is easier to
read separate tasks.
Another issue is that this code shall probably be optional, so I would
need to make this feature somehow dependent on some flag ...
Any good suggestions? PACKAGECONFIG seems like a good starting point ?
>
> Cheers,
>
> Richard
>
>
>
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpF0tdaS2eUd.pgp
Description: OpenPGP digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils
On Wed, 2019-07-10 at 11:06 +0800, ChenQi wrote:
> On 07/09/2019 06:18 PM, Richard Purdie wrote:
> > On Tue, 2019-07-09 at 17:36 +0800, ChenQi wrote:
> > What happens if we add:
> >
> > ${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation',
> > 'nativesdk-libxml2', '', d)} \
> >
> > to
> > `
> > meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> >
> > ?
>
> This does not work. Using nativesdk-libxml2-utils does not work too.
> Both buildtools and eSDK do not use this packagegroup.
Ok, I'll need to spend more time looking at the problem then :(.
> I've sent out a V2 of this patch, with change to put the
> 'libxml2-native' dependency in xmlcatalog.bbclass.
> In this way, we can ensure that the xmlcatalog is from our recipe.
> In normal build, it's from libxml2-native; in build-sysroots in eSDK,
> it's from nativesdk-libxml2-utils. Do you think this is acceptable?
The class change is fine and I'll queue that.
We are not adding xmlcatalog to HOSTTOOLS_NONFATAL however, that is
simply not an option or the right way to fix this.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Provide tasks to generate default U-Boot environment(s) images
On Tue, 2019-07-09 at 16:20 +0200, Lukasz Majewski wrote:
> This change provides tasks to generate default U-Boot environment images
> from built U-Boot (via. get_default_envs.sh script).
>
> Those images then can be used to generate wic images (with e.g. eMMC layout).
> With such approach the end user doesn't see the "CRC environment" error
> after the first boot.
>
> Moreover, those are built per MACHINE (as u-boot itself is) so then could
> be used in SWUpdate scenarios with single tar'ed archive with multiple
> MACHINE specific *.swu images.
>
> It is also possible to adjust the *_ENVS_* variables in machine specific
> conf file.
>
> Test:
> Newest master-next for poky repo - SHA1:
> eb5b0a0b5e53a6e55a09e66489d3f24d0c6232ee
> MACHINE = "beaglebone-yocto" in local.conf
> bitbake virtual/bootloader
>
>
> As a result following links are available in deploy directory:
> u-boot-env.img{_r}.
>
> Signed-off-by: Lukasz Majewski
> ---
> meta/recipes-bsp/u-boot/u-boot.inc | 41
> ++
> 1 file changed, 41 insertions(+)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 9a754fd09b..e0ccf1ce1f 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -331,3 +331,44 @@ do_deploy () {
> }
>
> addtask deploy before do_build after do_compile
> +
> +# Extract default envs from build U-Boot
> +DEFAULT_UBOOT_ENVS_FILE ?= "u-boot-env"
> +DEFAULT_ENVS ?= "${DEFAULT_UBOOT_ENVS_FILE}.txt"
> +UBOOT_ENVS_DEFAULT ?= "${DEFAULT_UBOOT_ENVS_FILE}-${MACHINE}-${PV}-${PR}.img"
> +UBOOT_ENVS_SIZE ?= "65536"
> +
> +# Generate default environment
> +do_gen_default_envs[doc] = "Generate image with default U-Boot
> environment(s)"
> +do_gen_default_envs () {
> +${B}/source/scripts/get_default_envs.sh ${B} > ${B}/${DEFAULT_ENVS}
> +
> +# Generate env image
> +${B}/tools/mkenvimage -s ${UBOOT_ENVS_SIZE} -o
> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
> +
> +# Generate redundant env image
> +${B}/tools/mkenvimage -r -s ${UBOOT_ENVS_SIZE} -o
> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
> +
> +rm ${B}/${DEFAULT_ENVS}
> +}
> +
> +addtask gen_default_envs before do_deploy after do_compile
> +
> +# Deploy default environment
> +do_deploy_default_envs[doc] = "Copy images with default U-Boot environment
> to deployment directory"
> +do_deploy_default_envs () {
> +
> + install -d ${DEPLOYDIR}
> +
> + install ${B}/${UBOOT_ENVS_DEFAULT} ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}
> + install ${B}/${UBOOT_ENVS_DEFAULT}_r
> ${DEPLOYDIR}/${UBOOT_ENVS_DEFAULT}_r
> +
> + cd ${DEPLOYDIR}
> + ln -sf ${UBOOT_ENVS_DEFAULT} ${DEFAULT_UBOOT_ENVS_FILE}.img
> + ln -sf ${UBOOT_ENVS_DEFAULT}_r ${DEFAULT_UBOOT_ENVS_FILE}.img_r
> +
> + rm ${B}/${UBOOT_ENVS_DEFAULT}
> + rm ${B}/${UBOOT_ENVS_DEFAULT}_r
> +}
> +
> +addtask deploy_default_envs before do_deploy after do_gen_default_envs
I'm not sure this second function/task is right.
DEPLOYDIR is really "owned" by the do_deploy function. As such, if you
rerun the deploy task, it should be recreated with the right content.
By default I appreciate that deploy.bbclass doesn't wipe out the
directory but it probably should to make it clear what the expectations
are here.
I don't think it would cause a real problem right now, until files
changed names or something in one of these tasks, then you'd end up
with files you didn't expect since nothing ever cleans this directory.
Is there a reason we can't make this part of do_deploy and clean the
directory at the start of do_deploy?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] config warning from linux-yocto 4.19
Hi Bruce, I think/hope this is just a kernel config srcrev update but could you fix: """ WARNING: linux-yocto-4.19.44+gitAUTOINC+ad235db461_c12bc1a098-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration: -- CONFIG_SCSI_DEBUG - Config: CONFIG_SCSI_DEBUG From: /home/pokybuild/yocto-worker/qemuarm-lsb/build/build/tmp/work-shared/qemuarm/kernel-source/.kernel-meta/configs/v4.19/standard/qemuarma15/features/scsi/scsi-debug.cfg Requested value: CONFIG_SCSI_DEBUG=m Actual value: No reference to SCSI_DEBUG found """ please? :) We're fairly warning free on the autobuilder now so this one sticks out badly! https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/804 (its qemuarm with poky-lsb) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 3/4] gtk+: remove GTK+ 2
On Fri, 2019-07-05 at 17:20 +0100, Ross Burton wrote: > GTK+ 2 is ancient, and shouldn't be used. It will be moved to meta- > oe for > people who do need it, but it shouldn't in oe-core. > > [ YOCTO #12673 ] I agree its time to do this, its in keeping with various other old software we've been cleaning up. Builds with this included didn't work as its referenced by a selftest: test_recipetool_create_cmake Also the maintainers entry remains... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] openssl: fix multilib files conflict
From: Kai Kang
Inherit multilib_script to fix openssl multilib files conflict issue:
| Error: Transaction check error:
| file /usr/bin/c_rehash conflicts between attempted installs of
| lib32-openssl-bin-1.1.1c-r0.core2_32 and openssl-bin-1.1.1c-r0.core2_64
Signed-off-by: Kai Kang
---
meta/recipes-connectivity/openssl/openssl_1.1.1c.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb
index 0117407316..af43d6992c 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb
@@ -26,7 +26,8 @@ SRC_URI_append_class-nativesdk = " \
SRC_URI[md5sum] = "15e21da6efe8aa0e0768ffd8cd37a5f6"
SRC_URI[sha256sum] =
"f6fb3079ad15076154eda9413fed42877d668e7069d9b87396d0804fdb3f4c90"
-inherit lib_package multilib_header ptest
+inherit lib_package multilib_header multilib_script ptest
+MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
PACKAGECONFIG ?= ""
PACKAGECONFIG_class-native = ""
--
2.20.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-fitimage: uboot-sign: fix missing signature
u-boot.bin with dtb & signature should be placed in ${B} so that
it can be deployed by u-boot as expected. Otherwise, the version
without signature is installed.
Signed-off-by: Jun Nie
---
meta/classes/uboot-sign.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 8beafff..1fc2a37 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -66,7 +66,7 @@ concat_dtb_helper() {
install ${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e
"$deployed_uboot_dtb_binary" ]; then
cd ${DEPLOYDIR}
- cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary | tee
${UBOOT_BINARY} > ${UBOOT_IMAGE}
+ cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary | tee
${B}/${CONFIG_B_PATH}/${UBOOT_BINARY} > ${UBOOT_IMAGE}
else
bbwarn "Failure while adding public key to u-boot binary.
Verified boot won't be available."
fi
@@ -77,10 +77,12 @@ concat_dtb() {
mkdir -p ${DEPLOYDIR}
if [ -n "${UBOOT_CONFIG}" ]; then
for config in ${UBOOT_MACHINE}; do
+ CONFIG_B_PATH="${config}"
cd ${B}/${config}
concat_dtb_helper
done
else
+ CONFIG_B_PATH=""
cd ${B}
concat_dtb_helper
fi
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
