Re: [yocto] Warrior, extended SDK

[Khem Raj]

On Sat, Jun 22, 2019 at 1:37 PM Peter Balazovic
 wrote:
>
> Hello guys
>
> I'm trying to generate extended SDK under Yocto-Warrior and getting error 
> such as
>
> ERROR: image-qt5-1.0-r0 do_sdk_depends: The file 
> /usr/include/tensorflow/contrib/lite/string_util.h is installed by both 
> tensorflow and tensorflow-lite, aborting
> ERROR: image-qt5-1.0-r0 do_sdk_depends:
> ERROR: image-qt5-1.0-r0 do_sdk_depends: Function failed: extend_recipe_sysroot
>
> can you help me identify an issue on this fail?
>

you are including two packages which are providing same file. Only one
of those should be providing the file, either delete it or rename it
in other recipe if both packages
are to be installed side by side

> Thanks.
> Peter
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder2][PATCH 2/3] Added remote distribution of config JSON files

[Thomas Goodwin]

This feature/fix allows the worker to download the
autobuilder helper JSON files from the controller
rather than having to store them in the
yocto-autobuilder-helper repository.  The process
installs the file into the worker's
builddir/yocto-autobuilder-helper path.

Signed-off-by: Thomas Goodwin 
---
 builders.py | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/builders.py b/builders.py
index 3d12969..35903de 100644
--- a/builders.py
+++ b/builders.py
@@ -18,6 +18,26 @@ extra_env = {}
 if os.environ.get('ABHELPER_JSON'):
 extra_env['ABHELPER_JSON'] = os.environ['ABHELPER_JSON']
 
+def add_abhelper_steps(factory):
+"""
+Adds FileDownload steps to the factory for each specified autobuilder
+helper JSON file and installs the file in the worker's
+builddir/yocto-autobuilder-helper/ path.
+"""
+abhelper_dir = os.path.expanduser("~/yocto-autobuilder-helper")
+abhelper_configs = extra_env.get("ABHELPER_JSON", "config.json").split(" ")
+for helper in abhelper_configs:
+helper_name = os.path.basename(helper)
+worker_helper = 
util.Interpolate("%(prop:builddir)s/yocto-autobuilder-helper/" + helper_name)
+master_helper = helper
+if not helper.startswith("/"):
+master_helper = os.path.join(abhelper_dir, helper)
+factory.addStep(steps.FileDownload(
+name="Download '{}'".format(helper_name),
+mastersrc=master_helper,
+workerdest=worker_helper,
+haltOnFailure=True ))
+
 @util.renderer
 def get_sstate_release_number(props):
 """
@@ -145,6 +165,7 @@ def create_builder_factory():
 mode='incremental',
 haltOnFailure=True,
 name='Fetch yocto-autobuilder-helper'))
+add_abhelper_steps(f)
 f.addStep(steps.SetProperties(properties=ensure_props_set))
 f.addStep(WriteLayerInfo(name='Write main layerinfo.json', 
haltOnFailure=True))
 f.addStep(steps.ShellCommand(
@@ -213,6 +234,7 @@ def create_parent_builder_factory(buildername, waitname):
 mode='incremental',
 haltOnFailure=True,
 name='Fetch yocto-autobuilder-helper'))
+add_abhelper_steps(factory)
 factory.addStep(WriteLayerInfo(name='Write main layerinfo.json', 
haltOnFailure=True))
 factory.addStep(steps.ShellCommand(
 command=[
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder2][PATCH 3/3] Support for absolute paths to config files

[Thomas Goodwin]

Using absolute paths in ABHELPER_JSON with remote-loading
now works; the paths are stripped to os.path.basename()
before being provided to the builders.

Signed-off-by: Thomas Goodwin 
---
 builders.py | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/builders.py b/builders.py
index 35903de..16c1344 100644
--- a/builders.py
+++ b/builders.py
@@ -4,6 +4,7 @@ from yoctoabb import config
 from yoctoabb.steps.writelayerinfo import WriteLayerInfo
 from yoctoabb.steps.observer import RunConfigLogObserver
 from datetime import datetime
+import copy
 
 import os
 import json
@@ -38,6 +39,13 @@ def add_abhelper_steps(factory):
 workerdest=worker_helper,
 haltOnFailure=True ))
 
+# At the worker, all paths are relative to builddir/yocto-autobuilder-helper
+# once the add_abhelper_steps run.
+worker_env = copy.deepcopy(extra_env)
+if worker_env.get('ABHELPER_JSON'):
+configs = [os.path.basename(c) for c in 
worker_env['ABHELPER_JSON'].split(" ")]
+worker_env['ABHELPER_JSON'] = " ".join(configs)
+
 @util.renderer
 def get_sstate_release_number(props):
 """
@@ -216,7 +224,7 @@ for builder in config.subbuilders:
 workers = config.builder_to_workers['default']
 builders.append(util.BuilderConfig(name=builder,
workernames=workers,
-   factory=f, env=extra_env))
+   factory=f, env=worker_env))
 
 def create_parent_builder_factory(buildername, waitname):
 factory = util.BuildFactory()
@@ -337,5 +345,5 @@ def create_parent_builder_factory(buildername, waitname):
 
 return factory
 
-builders.append(util.BuilderConfig(name="a-quick", workernames=config.workers, 
factory=create_parent_builder_factory("a-quick", "wait-quick"), env=extra_env))
-builders.append(util.BuilderConfig(name="a-full", workernames=config.workers, 
factory=create_parent_builder_factory("a-full", "wait-full"), env=extra_env))
+builders.append(util.BuilderConfig(name="a-quick", workernames=config.workers, 
factory=create_parent_builder_factory("a-quick", "wait-quick"), env=worker_env))
+builders.append(util.BuilderConfig(name="a-full", workernames=config.workers, 
factory=create_parent_builder_factory("a-full", "wait-full"), env=worker_env))
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder2][PATCH 1/3] Bug fix: added support for ABHELPER_JSON environ.

[Thomas Goodwin]

The readme suggests exporting this variable from the
environment to expose multiple configuration JSON files
but the intended behavior doesn't work without adding the
variable to extra_env.

Signed-off-by: Thomas Goodwin 
---
 builders.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/builders.py b/builders.py
index 5765040..3d12969 100644
--- a/builders.py
+++ b/builders.py
@@ -15,7 +15,8 @@ maxsteps = 9
 # Environment to pass into the workers, e.g. to load further local 
configuration
 # fragments
 extra_env = {}
-#extra_env = {"ABHELPER_JSON" : "config.json 
/home/pokybuild/config-local.json"}
+if os.environ.get('ABHELPER_JSON'):
+extra_env['ABHELPER_JSON'] = os.environ['ABHELPER_JSON']
 
 @util.renderer
 def get_sstate_release_number(props):
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Minutes: Yocto Project Weekly Meeting 7/30/2019

[Reyna, David]

Yocto Project Weekly Meeting
MINUTES: 7/30/2019

Attendees: Richard, Michael, JoshuaW, Ross, Tim, David, Trevor, Jan-Simon

Note: consolidated bridge for Tuesday meetings: https://zoom.us/j/990892712

Richard:
  * Weekly status update will go out later today
  * 2.8 (3.0) M2 sent to QA
  * 2.6.3. ready to build, then QA
  * The Technical Steering Committee (TSC) updated their Wiki mission page 
(https://wiki.yoctoproject.org/wiki/TSC), stressing that they are the committee 
of last resort.
  * Mentioned again the YP-2.8 will be renamed as YP-3.0. Michael noted that we 
need to change the hold release “2.99” to “3.99”.
  * With working with the optimization patches, may want to break/cleanup API, 
specifically around task naming (e.g. array, filename-XXX, filename:XXX)
  * Hash equivalency work is breaking the eSDK. Joshua offered to help, noted 
that they do not use the eSDK and therefore had not tested against it.
  * Linux Foundation has launched a New Community Bridge 
(https://www.linuxfoundation.org/press-release/2019/03/the-linux-foundation-launches-new-communitybridge-platform-to-help-sustain-open-source-communities/).
 Nico has forwarded this to the YP community to encourage mentors/mentees.
  * We are slightly behind schedule for M2, but wanted to get the runqueue 
patches in and part of the QA

Joshua: Reproducible builds, wants to know why simple class is different. Ross 
will ping Juro. Richard recalls the more complex class was to get sensible 
dates, and it has been working very well to date (with a few exceptions), and 
there may be a bug in the reproducibility build class. Richard is aiming for 
reproducibility build tests, and these builds are the builds to prove it [to us 
and to the general community].

Joshua: RSS (?) versus host tools. There are issues, for example perl-native 
man pages can get different dates in the text depending if it is pulled from 
host or cache. We should review host tools versus native tools. Richard: 
specifically host tools to build native and then native to build target, and 
there should never be docs built for native.

Richard: Goal for YP-3.0 reproducibility. Joshua: is there something on 
autobuilder yet?

Richard: Running more Autobuilder full builds as opposed to quick builds to 
help flush out issues with recent big changes (e.g. runqueue). Full builds 1-3 
times a weeks, cover pTest/LTP/build stats for x64 and arm64.

Tim: working with data analytics team in Intel, analyzing QA logs. Poses 
question to group: “what questions do we want to answer from the data?”. This 
will help guide the effort to extract meaningful results. Richard: noted that 
build performance is in a different database than what they are looking at 
right now.

Tim: Ported Autobuilder to Intel. Will update the wiki with learned lessons 
(e.g. local layers). Discovered that putting the sstats-cache on an NFS server 
brought the system to a crawl, was considering SSHFS. Local builds fast, but 
cache not shared. Richard noted the issue is that git does a lock on repos 
during check, and is slow/blocking especially for repos with long history. 
There was a fix/alternate process where the build is local and then the results 
copied to shared cache. Will provide patch to Tim, this is simpler that SSHFS. 
Noted that the Autobuilder was designed against YP’s build cluster. Tim noted 
that all the work on shared-caches over the years really helps.

Trevor: happy but curious why YP finally adopted “gsock”? Richard: still has 
concerns but will give it a go,  community and general experience has moved 
forward significantly over time, plus the fact it is LF project. We do need 
people to pick this up (not RP).

Tim: for community bridge topic, notes that care should be taken in choosing 
mentees: some become long term contributors, some never execute. Asked if there 
was any funding for mentees? Richard: there is some matching funds from LF 
especially for the underserved, also could get some support from YP sponsors. 
Trevor gave kudos to Xlinx.

- David


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW31'19

[sjolley.yp.pm]

Current Dev Position: YP 2.8 M3

Next Deadline: YP 2.8 Milestone M3 Cutoff (Feature Freeze) Aug 25, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Paul 
*   SWAT team rotation: Paul -> Ross on Aug. 2, 2019
*   SWAT team rotation: Ross -> Amanda on Aug. 9, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   Bug Triage meeting Thursday August 1st at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday August 6th at 8am PDT (
 https://zoom.us/j/990892712) 
*   Twitch - Next event is Tuesday August 6th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   YP 2.8 M2 rc1 is in QA which is due to complete on Wednesday
*   YP 2.6.3 will build to go into QA on Wednesday
*   We have a new "newcomer" bug category which are bugs suited to
someone new to the project. These can be seen here:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
*   The Yocto Project TSC has determined how it plans to operate and put
the details into the appropriate wiki page:

https://wiki.yoctoproject.org/wiki/TSC. It is intended as a decision making
body of last resort, if there are issues people wish it to address, please
raise them with one of its members.
*   After discussion in various places its been agreed that the next
project release will be "3.0", to replace "2.8". The 2.8 placeholder may
continue to be used, particularly in the bugzilla. There are many good
reasons to bump the version, the most recent being the runqueue changes
allowing build optimizations based upon output equivalence (see below) but
also including the new project governance, the autobuilder, improved test
coverage any many other things.
*   There are patches available which enable runqueue optimisations
based on output comparisons of tasks. This removes the need to run later
tasks if the output is unchanged and is based upon the previous hash
equivalence server work. This feature should be a significant win for the
users and is now working to a level where we'll likely make this a key
feature of the next release. These patches are being tested in master-next
at present.
*   There are also changes in -next which are being considered which
change several bitbake APIs around runqueue. The feeling is now may be the
best time to clean up several interfaces. If there are other API fixes
people want to see, now is a good time to mention them.
*   The project is working on some mentor and mentee opportunities.
Please see the separate email from Nicolas on the yocto list about this.

 

Planned Releases for YP 2.8:

*   M2 is in QA
*   M2 Release 26th July
*   M3 Cutoff (Feature Freeze) 25th Aug
*   M3 Release 6th Sept
*   M4 Cutoff 30th Sept
*   2.8 (M4) Final Release 25th Oct

 

Planned upcoming dot releases:

*   YP 2.7.2 (Warrior) is planned for after 2.8 M2  release.
*   YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
before 2.8 M3.

 

Tracking Metrics:

*   WDD 2466 (last week 2483) (

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

*   Total patches found: 1498 (last week 1499)
*   Patches in the Pending State: 619 (41%) [last week 623 (42%)]

 

Key Status Links for YP:

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

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

 
https://wiki.yoctoproject.org/wiki/Yocto_2.8_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
 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] LF Community Bridge Mentorship

[Nicolas Dechesne]

Dear all,

The Community Bridge platform was launched earlier this year by the
Linux Foundation. It’s a set of services available to LF projects to
help them build stronger ecosystems, and foster developers
relationship within their respective communities. See [1] and [2]. The
Yocto Project has joined the Community Bridge Funding and Mentorship
programs.

If you have any specific questions about these programs, please do not
hesitate to reach out to me.

Today, we would like to talk more about the mentorship program. We
have tried several initiatives in the past about interns and
mentorship, and we would like to do that again using the new LF
platform. A mentorship program for the Yocto Project is a good
opportunity for our overall community to reach out to new developers,
improve our developers diversity. It will help increase the pool of
available developers with appropriate skills about the Yocto Project
and Open Embedded technologies and as a consequence create a more
sustainable ecosystem around the Yocto Project. It also offers
existing senior developers the chance to become mentors, and share
their knowledge!

We would like to request feedback about how to best define the Yocto
Project Mentorship program.

The structure of the mentorship is flexible and we can adjust as
needed. Our initial thought is to set 12-week project, which is what
the Linux Kernel Mentorship program is using, see [4]. The overall
process involves:

1. Finding / defining work items for potential mentees.
2. Get appropriate funding for mentees’ stipends
3. Recruit mentors within our community
4. Review and select mentees’ applications

There has already been some work on the potential work items in the
form of the newcomer bugs, some of which could be turned into work
suitable for a mentorship programme.

=== Call for ACTION ===

* We need your help for any of the items above, and especially #1 to
get started. Whether you are a long time contributor to the project or
you recently joined our mailing list, your feedback will be greatly
appreciated.
* If you are interested to participate as a mentor, please let me know!
* You don’t need to be a project expert to be a mentor, you need to
know how the project works and be willing to help guide someone
through their task.

There is no specific timeline set yet, it will most likely depend on
how much feedback we receive about this initiative, but most likely
the internships will have to be tied to the Yocto Project release
timeline.

If you have any questions or any suggestions, please reach out to me!
cheers,
Nico

[1] 
https://www.linuxfoundation.org/press-release/2019/03/the-linux-foundation-launches-new-communitybridge-platform-to-help-sustain-open-source-communities/
[2] https://communitybridge.org/
[3] https://people.communitybridge.org/
[4] https://wiki.linuxfoundation.org/lkmp
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK: getting error "xmlcatalog: not found" installing SDK

[baisch]

Hello,

after updating to warrior 2.7.1 from thud and trying to install the Extensible 
SDK again I'm getting the following error:

```
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_build_native_sysroot(d)
 0003:
File: '/workdir/sdk/rpi/layers/poky/meta/recipes-core/meta/build-sysroots.bb', 
lineno: 23, function: do_build_native_sysroot
 0019:
 0020:python do_build_native_sysroot () {
 0021:targetsysroot = d.getVar("STANDALONE_SYSROOT")
 0022:nativesysroot = d.getVar("STANDALONE_SYSROOT_NATIVE")
 *** 0023:staging_populate_sysroot_dir(targetsysroot, nativesysroot, True, 
d)
 0024:}
 0025:do_build_native_sysroot[cleandirs] = "${STANDALONE_SYSROOT_NATIVE}"
 0026:do_build_native_sysroot[nostamp] = "1"
 0027:addtask do_build_native_sysroot before do_build
File: '/workdir/sdk/rpi/layers/poky/meta/classes/staging.bbclass', lineno: 235, 
function: staging_populate_sysroot_dir
 0231:continue
 0232:
 0233:staging_processfixme(fixme, targetdir, targetsysroot, 
nativesysroot, d)
 0234:for p in postinsts:
 *** 0235:subprocess.check_output(p, shell=True, 
stderr=subprocess.STDOUT)
 0236:
 0237:#
 0238:# Manifests here are complicated. The main sysroot area has the 
unpacked sstate
 0239:# which us unrelocated and tracked by the main sstate manifests. Each 
recipe
File: 
'/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
 lineno: 395, function: check_output
 0391:# empty string. That is maintained here for backwards 
compatibility.
 0392:kwargs['input'] = '' if kwargs.get('universal_newlines', 
False) else b''
 0393:
 0394:return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
 *** 0395:   **kwargs).stdout
 0396:
 0397:
 0398:class CompletedProcess(object):
 0399:"""A process that has finished running.
File: 
'/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
 lineno: 487, function: run
 0483:raise
 0484:retcode = process.poll()
 0485:if check and retcode:
 0486:raise CalledProcessError(retcode, process.args,
 *** 0487: output=stdout, stderr=stderr)
 0488:return CompletedProcess(process.args, retcode, stdout, stderr)
 0489:
 0490:
 0491:def list2cmdline(seq):
Exception: subprocess.CalledProcessError: Command 
'/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog'
 returned non-zero exit status 127.

Subprocess output:
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 5: 
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 xmlcatalog: not found
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 8: 
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 xmlcatalog: not found
```

I believe the problem is that in the 
`postinst-docbook-xsl-stylesheets-native-xmlcatalog`, `xmlcatalog` is not an 
absolute path and thus not found.
This can be traced to the new `layers/poky/meta/classes/xmlcatalog.bbclass`. I 
tried to change `xmlcatalog` to `${SYSROOT_DESTDIR}${bindir}/xmlcatalog` there, 
but even after cleaning the `docbook-xsl-stylesheets` recipe this change had no 
effect. I'm not sure if this class is cached somewhere else or something.

Can someone help me getting the SDK to work again, and maybe this is general 
thing with needs to be fixed?


Thank you.

Regards,

- Michael
-- 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] linux-yocto-dev falls back to v5.2

[Bruce Ashfield]

See the email on the poky/oe-core list. I was having some issues with 5.3
and the new libc-headers. So I wasn't able to send the PV bump patch for
linux-yocto. I've temporarily gone back to a building configuration, but I
expect that I'll have it back to 5.3 in the next day or so.

Bruce

On Tue, Jul 30, 2019 at 2:58 AM He Zhe  wrote:

> Hi Bruce,
>
> Why do we merge v5.2.3 to linux-yocto-dev? which is now almost the same as
> linux-yocto.
>
> Regards,
> Zhe
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Why does enabling initramfs pull eudev into my build?

[Patrick Doyle]

On Mon, Jul 29, 2019 at 10:52 AM Patrick Doyle  wrote:
>
> Did that get your attention? :-)
>
> I am trying to understand why eudev gets pulled into my build, where
> it wasn't part of it before.  I recently added an initramfs to my
> build...
What I neglected to say was that a colleague of mine had recently
added crda to our build as well, and that recipe has an explicit
RDEPENDS on "udev".

I did spend an interesting day learning about the difference between
recipes that RDEPEND on providers and individual packages that RDEPEND
on providers.  I was confused by the fact that the
initramfs-framework_1.0.bb recipe contains:

SUMMARY_initramfs-module-udev = "initramfs support for udev"
RDEPENDS_initramfs-module-udev = "${PN}-base udev"
FILES_initramfs-module-udev = "/init.d/01-udev"

and, since I didn't depend/rdepend on initramfs-module-udev anywhere
in my build, why that resulted in udev being included in my build.

The answer is... it doesn't.  crda caused it to be included in my build.

Thanks for listening.

--wpd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-security] keyutils: migrate to meta-oe

[akuster808]

On 7/29/19 3:47 AM, dbarysh...@gmail.com wrote:
> From: Dmitry Eremin-Solenikov 
>
> keyutils are now part of meta-oe, so remove them from meta-security.

This should be sitting in master-next already

- armin
>
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
>  .../files/fix_library_install_path.patch  | 28 --
>  ...ror-report-by-adding-default-message.patch | 42 ---
>  .../keyutils-test-fix-output-format.patch | 41 --
>  recipes-security/keyutils/files/run-ptest |  3 --
>  recipes-security/keyutils/keyutils_1.6.bb | 53 ---
>  5 files changed, 167 deletions(-)
>  delete mode 100644 
> recipes-security/keyutils/files/fix_library_install_path.patch
>  delete mode 100644 
> recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
>  delete mode 100644 
> recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
>  delete mode 100755 recipes-security/keyutils/files/run-ptest
>  delete mode 100644 recipes-security/keyutils/keyutils_1.6.bb
>
> diff --git a/recipes-security/keyutils/files/fix_library_install_path.patch 
> b/recipes-security/keyutils/files/fix_library_install_path.patch
> deleted file mode 100644
> index 938fe2eb57a4..
> --- a/recipes-security/keyutils/files/fix_library_install_path.patch
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -From b0355cc205543ffd33752874295139d57c4fbc3e Mon Sep 17 00:00:00 2001
> -From: Wenzong Fan 
> -Date: Tue, 26 Sep 2017 07:59:51 +
> -Subject: [PATCH] Subject: [PATCH] keyutils: use relative path for link
> -
> -The absolute path of the symlink will be invalid
> -when populated in sysroot, so use relative path instead.
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Jackie Huang 
> -Signed-off-by: Wenzong Fan 
> -{rebased for 1.6]
> -Signed-off-by: Armin Kuster 
> -
> -Index: keyutils-1.6/Makefile
> -===
>  keyutils-1.6.orig/Makefile
> -+++ keyutils-1.6/Makefile
> -@@ -184,7 +184,7 @@ ifeq ($(NO_SOLIB),0)
> - $(INSTALL) -D $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME)
> - $(LNS) $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(SONAME)
> - mkdir -p $(DESTDIR)$(USRLIBDIR)
> --$(LNS) $(LIBDIR)/$(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> -+$(LNS) $(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> - sed \
> - -e 's,@VERSION\@,$(VERSION),g' \
> - -e 's,@prefix\@,$(PREFIX),g' \
> diff --git 
> a/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
>  
> b/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
> deleted file mode 100644
> index acd91c01c483..
> --- 
> a/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -fix keyutils test error report
> -
> -Upstream-Status: Pending
> -
> -"Permission denied" may be the reason of EKEYEXPIRED and EKEYREVOKED.
> -"Required key not available" may be the reason of EKEYREVOKED.
> -EXPIRED and REVOKED are 2 status of kernel security keys features.
> -But the userspace keyutils lib will output the error message, which may
> -have several reasons.
> -
> -Signed-off-by: Han Chao 
> -
> -diff --git a/tests/toolbox.inc.sh b/tests/toolbox.inc.sh
> -index bbca00a..739e9d0 100644
>  a/tests/toolbox.inc.sh
> -+++ b/tests/toolbox.inc.sh
> -@@ -227,11 +227,12 @@ function expect_error ()
> - ;;
> - EKEYEXPIRED)
> - my_err="Key has expired"
> --alt_err="Unknown error 127"
> -+alt_err="Permission denied"
> - ;;
> - EKEYREVOKED)
> - my_err="Key has been revoked"
> --alt_err="Unknown error 128"
> -+alt_err="Permission denied"
> -+alt2_err="Required key not available"
> - ;;
> - EKEYREJECTED)
> - my_err="Key has been rejected"
> -@@ -249,6 +250,9 @@ function expect_error ()
> - elif [ "x$alt_err" != "x" ] && expr "$my_errmsg" : ".*: $alt_err" 
> >&/dev/null
> - then
> - :
> -+elif [ "x$alt2_err" != "x" ] && expr "$my_errmsg" : ".*: $alt2_err" 
> >&/dev/null
> -+then
> -+:
> - elif [ "x$old_err" != "x" ] && expr "$my_errmsg" : ".*: $old_err" 
> >&/dev/null
> - then
> - :
> -
> diff --git 
> a/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch 
> b/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
> deleted file mode 100644
> index a4ffd50ce54c..
> --- a/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -From 49b6321368e4bd3cd233d045cd09004ddd7968b2 Mon Sep 17 00:00:00 2001
> -From: Jackie Huang 
> -Date: Mon, 15 May 2017 14:52:00 +0800
> -Subject: [PATCH] keyutils: fix output format
> -
> -keyutils ptest output format is incorrect, according to yocto
> -Development Manual
> 

[linux-yocto] linux-yocto-dev falls back to v5.2

[He Zhe]

Hi Bruce,

Why do we merge v5.2.3 to linux-yocto-dev? which is now almost the same as 
linux-yocto.

Regards,
Zhe
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto