Re: [OE-core] [PATCH] pseudo: Remove mismatched inodes from the db

[Richard Purdie]

On Tue, 2020-09-22 at 12:52 -0500, Seebs wrote:
> On Tue, 22 Sep 2020 18:22:18 +0100
> "Richard Purdie"  wrote:
> 
> > The "fun" here is that "make install" is rewriting Makefiles within
> > the source code tree. The install step runs under pseudo, earlier
> > ones do not.
> > If we rerun earlier non-pseudo steps, the Makefiles get reset to
> > their
> > original state, then "make install" modifies them again.
> 
> ugh.
> 
> Okay, so. A vague thought about how to perhaps approach this: A
> post-install step, which basically does:
>   pseudo cp Makefile Makefile.pseudo
>   pseudo rm Makefile
>   [not-pseudo] cp Makefile.pseudo Makefile
>   pseudo rm Makefile.pseudo
>
> So that, at the end of the post-install, the files pseudo doesn't
> want
> to know about are forgotten. Possibly there ought to be a "forget
> about
> this directory" option/command.

We're not going to know the exact files unfortunately so it would
likely need to be an "all paths starting with XXX, YYY" type command.

A quick scan of my TMPDIR shows 17,000 of these path mismatches and I'm
not sure there is a single path in there we care about, it does mean a
lot of permissions are being mangled though :(

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142728): 
https://lists.openembedded.org/g/openembedded-core/message/142728
Mute This Topic: https://lists.openembedded.org/mt/77012533/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] pseudo: Remove mismatched inodes from the db

[Seebs]

On Tue, 22 Sep 2020 18:22:18 +0100
"Richard Purdie"  wrote:

> The "fun" here is that "make install" is rewriting Makefiles within
> the source code tree. The install step runs under pseudo, earlier
> ones do not.

> If we rerun earlier non-pseudo steps, the Makefiles get reset to their
> original state, then "make install" modifies them again.

ugh.

Okay, so. A vague thought about how to perhaps approach this: A
post-install step, which basically does:
pseudo cp Makefile Makefile.pseudo
pseudo rm Makefile
[not-pseudo] cp Makefile.pseudo Makefile
pseudo rm Makefile.pseudo

So that, at the end of the post-install, the files pseudo doesn't want
to know about are forgotten. Possibly there ought to be a "forget about
this directory" option/command.

-s

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142727): 
https://lists.openembedded.org/g/openembedded-core/message/142727
Mute This Topic: https://lists.openembedded.org/mt/77012533/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] pseudo: Remove mismatched inodes from the db

[Richard Purdie]

On Tue, 2020-09-22 at 11:06 -0500, Seebs wrote:
> On Tue, 22 Sep 2020 14:18:24 +0100
> "Richard Purdie"  wrote:
> 
> > This can happen when files are deleted outside of pseudo context and
> > the inode is reused by a new file which pseduo then "sees".
> 
> In terms of the original design: This would be considered a usage bug,
> and pseudo issues diagnostics for that. Once files are owned by an
> instance of pseudo, it expects to "see" every change to those files,
> and if you don't do that, then yes, the database is corrupt. But in
> some cases, the behavior was something like "a move within a pseudo
> filesystem" or something similar, and losing the data would also be
> bad.
> 
> Basically, the original design philosophy is that you should *never*
> be modifying things pseudo owns outside of pseudo. And that does impose
> a performance cost on things, *but*, it also gives us a lot of
> confidence in results.

The "fun" here is that "make install" is rewriting Makefiles within the
source code tree. The install step runs under pseudo, earlier ones do
not.

If we rerun earlier non-pseudo steps, the Makefiles get reset to their
original state, then "make install" modifies them again.

We don't run unpack/configure/compile under pseudo for performance
reasons, these steps don't do anything we care about from a pseudo
perspective.

> So my preference on "deleting files outside of pseudo context, inode
> gets reused" would be "don't do that then"; this is why pseudo reports
> diagnostics for those. Being able to tell you what the old path was
> in such cases was actually one of the primary reasons pseudo exists.

We're not intentionally doing it. Perl's makefiles are doing crazy
things. I'm not sure we can:

a) afford to run everything under pseudo

or

b) catch every case of code which modifies files in unexpected places


Part of the trouble here is that we can't tell pseudo "only monitor
files ". Realistically, it can't expect to monitor every file on
the system either.

We are breaking pseudo's original design, but in general it seems to
work out fine (and we've been doing pretty this for many years now). We
may need to accept we're not operating entirely as designed and
consider if we could/should be changing some of the responses to these
corner cases accordingly as I don't think we can realistically avoid
them?

Not sure where this leaves us :(

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142726): 
https://lists.openembedded.org/g/openembedded-core/message/142726
Mute This Topic: https://lists.openembedded.org/mt/77012533/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] pseudo: Remove mismatched inodes from the db

[Seebs]

On Tue, 22 Sep 2020 14:18:24 +0100
"Richard Purdie"  wrote:

> This can happen when files are deleted outside of pseudo context and
> the inode is reused by a new file which pseduo then "sees".

In terms of the original design: This would be considered a usage bug,
and pseudo issues diagnostics for that. Once files are owned by an
instance of pseudo, it expects to "see" every change to those files,
and if you don't do that, then yes, the database is corrupt. But in
some cases, the behavior was something like "a move within a pseudo
filesystem" or something similar, and losing the data would also be
bad.

Basically, the original design philosophy is that you should *never*
be modifying things pseudo owns outside of pseudo. And that does impose
a performance cost on things, *but*, it also gives us a lot of
confidence in results.

So my preference on "deleting files outside of pseudo context, inode
gets reused" would be "don't do that then"; this is why pseudo reports
diagnostics for those. Being able to tell you what the old path was
in such cases was actually one of the primary reasons pseudo exists.

-s

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142725): 
https://lists.openembedded.org/g/openembedded-core/message/142725
Mute This Topic: https://lists.openembedded.org/mt/77012533/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 0/4] fix externalsrc task dependency issues

[Rasmus Villemoes]

This is all entirely untested, hence RFC. But if this doesn't work for
some reason, I think externalsrc.bbclass should grow some comments as
to why deltask is used instead of the noexec flag.

Patch 4 is a revert of patch 1, but I did it that way to facilitate
backporting, in case patch 2 is too dangerous for backporting. If that
is considered safe enough, it should be enough to apply patch 2 to
avoid the churn. In any case, patch 3 is just a little simplification
made possible by patch 2.


Rasmus Villemoes (4):
  kernel.bbclass: ensure symlink_kernsrc task gets run even with
externalsrc
  externalsrc.bbclass: make SRCTREECOVEREDTASKS noexec instead of
deleting them
  kernel-yocto.bbclass: remove now unnecessary externalsrc workaround
  Revert "kernel.bbclass: ensure symlink_kernsrc task gets run even with
externalsrc"

 meta/classes/externalsrc.bbclass  | 5 +
 meta/classes/kernel-yocto.bbclass | 6 --
 2 files changed, 1 insertion(+), 10 deletions(-)

-- 
2.23.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142720): 
https://lists.openembedded.org/g/openembedded-core/message/142720
Mute This Topic: https://lists.openembedded.org/mt/77015064/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 4/4] Revert "kernel.bbclass: ensure symlink_kernsrc task gets run even with externalsrc"

[Rasmus Villemoes]

With the changes to externalsrc.bbclass to make tasks noexec instead
of deleting them, we no longer need to explicitly make
do_symlink_kernsrc a dependency of do_configure.

Signed-off-by: Rasmus Villemoes 
---
 meta/classes/kernel.bbclass | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 78def5bbc1..48135b3d41 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -172,10 +172,7 @@ python do_symlink_kernsrc () {
 shutil.move(s, kernsrc)
 os.symlink(kernsrc, s)
 }
-# do_patch is normally ordered before do_configure, but
-# externalsrc.bbclass deletes do_patch, breaking the dependency of
-# do_configure on do_symlink_kernsrc.
-addtask symlink_kernsrc before do_patch do_configure after do_unpack
+addtask symlink_kernsrc before do_patch after do_unpack
 
 inherit kernel-arch deploy
 
-- 
2.23.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142724): 
https://lists.openembedded.org/g/openembedded-core/message/142724
Mute This Topic: https://lists.openembedded.org/mt/77015068/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 2/4] externalsrc.bbclass: make SRCTREECOVEREDTASKS noexec instead of deleting them

[Rasmus Villemoes]

The preferred way to prevent a task from running is not to deltask it,
but setting the noexec flag. That way various implicit dependencies
through the task in question are preserved, avoiding ad hoc
workarounds, such as the one right here.

Signed-off-by: Rasmus Villemoes 
---
 meta/classes/externalsrc.bbclass | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index d200129987..7b4d8b369f 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -100,14 +100,11 @@ python () {
 d.setVarFlag(task, 'cleandirs', ' '.join(cleandirs))
 
 fetch_tasks = ['do_fetch', 'do_unpack']
-# If we deltask do_patch, there's no dependency to ensure do_unpack 
gets run, so add one
-# Note that we cannot use d.appendVarFlag() here because deps is 
expected to be a list object, not a string
-d.setVarFlag('do_configure', 'deps', (d.getVarFlag('do_configure', 
'deps', False) or []) + ['do_unpack'])
 
 for task in d.getVar("SRCTREECOVEREDTASKS").split():
 if local_srcuri and task in fetch_tasks:
 continue
-bb.build.deltask(task, d)
+d.setVarFlag(task, 'noexec', '1')
 
 d.prependVarFlag('do_compile', 'prefuncs', 
"externalsrc_compile_prefunc ")
 d.prependVarFlag('do_configure', 'prefuncs', 
"externalsrc_configure_prefunc ")
-- 
2.23.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142722): 
https://lists.openembedded.org/g/openembedded-core/message/142722
Mute This Topic: https://lists.openembedded.org/mt/77015066/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 3/4] kernel-yocto.bbclass: remove now unnecessary externalsrc workaround

[Rasmus Villemoes]

Now that SRCTREECOVEREDTASKS gets marked as noexec rather than being
deltask'ed, do_kernel_configme is still ordered after do_patch (and
recursively, after do_unpack), so this workaround is no longer needed.

Signed-off-by: Rasmus Villemoes 
---
 meta/classes/kernel-yocto.bbclass | 6 --
 1 file changed, 6 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index a35c5923df..741b0b961c 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -656,12 +656,6 @@ python () {
 # If diffconfig is available, ensure it runs after kernel_configme
 if 'do_diffconfig' in d:
 bb.build.addtask('do_diffconfig', None, 'do_kernel_configme', d)
-
-externalsrc = d.getVar('EXTERNALSRC')
-if externalsrc:
-# If we deltask do_patch, do_kernel_configme is left without
-# dependencies and runs too early
-d.setVarFlag('do_kernel_configme', 'deps', 
(d.getVarFlag('do_kernel_configme', 'deps', False) or []) + ['do_unpack'])
 }
 
 # extra tasks
-- 
2.23.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142723): 
https://lists.openembedded.org/g/openembedded-core/message/142723
Mute This Topic: https://lists.openembedded.org/mt/77015067/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 1/4] kernel.bbclass: ensure symlink_kernsrc task gets run even with externalsrc

[Rasmus Villemoes]

Commit c5dfc2586b41 (kernel.bbclass: run do_symlink_kernsrc before
do_patch) fixed a race between do_symlink_kernsrc and
do_populate_lic. However, I missed the fact that when
externalsrc.bbclass is in use, the do_patch task doesn't exist,
meaning that do_symlink_kernsrc now doesn't get run at all, breaking
the build.

While I think the proper fix is to stop deltask'ing do_patch and
instead make it noexec in externalsrc.bbclass, a more targeted fix
suitable for backporting is to simply make this a dependency of both
do_patch and do_configure.

Fixes: c5dfc2586b41 (kernel.bbclass: run do_symlink_kernsrc before
do_patch)
Reported-by: Chanho Park 

Signed-off-by: Rasmus Villemoes 
---
 meta/classes/kernel.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 48135b3d41..78def5bbc1 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -172,7 +172,10 @@ python do_symlink_kernsrc () {
 shutil.move(s, kernsrc)
 os.symlink(kernsrc, s)
 }
-addtask symlink_kernsrc before do_patch after do_unpack
+# do_patch is normally ordered before do_configure, but
+# externalsrc.bbclass deletes do_patch, breaking the dependency of
+# do_configure on do_symlink_kernsrc.
+addtask symlink_kernsrc before do_patch do_configure after do_unpack
 
 inherit kernel-arch deploy
 
-- 
2.23.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142721): 
https://lists.openembedded.org/g/openembedded-core/message/142721
Mute This Topic: https://lists.openembedded.org/mt/77015065/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] distro_features_check: expand with MACHINE_FEATURES and COMBINED_FEATURES, rename

[Martin Jansa]

Can you please update the documentation to reflect this bbclass rename?

Patrick Vacek maintainer of meta-updater mentioned in one PR that the
documentation doesn't mention features_check.bbclass:
https://github.com/advancedtelematic/meta-updater/pull/771#issuecomment-683618949

It's mentioned in the "Moving to the Yocto Project 3.1 Release" section:
https://www.yoctoproject.org/docs/3.1.2/mega-manual/mega-manual.html#migration-3.1-features-check

but then all related variables and class reference only mention the old
distro_features_check name
https://www.yoctoproject.org/docs/3.1.2/mega-manual/mega-manual.html#var-REQUIRED_DISTRO_FEATURES
https://www.yoctoproject.org/docs/3.1.2/mega-manual/mega-manual.html#var-CONFLICT_DISTRO_FEATURES
https://www.yoctoproject.org/docs/3.1.2/mega-manual/mega-manual.html#ref-classes-distro_features_check

Not sure how this looks in the new sphinx generated documentation.

Thanks

On Sat, Nov 23, 2019 at 12:38 AM Denys Dmytriyenko  wrote:

> On Fri, Nov 22, 2019 at 06:16:39PM -0500, Denys Dmytriyenko wrote:
> > On Fri, Nov 22, 2019 at 11:10:14PM +, Richard Purdie wrote:
> > > On Fri, 2019-11-22 at 23:58 +0100, Andreas Müller wrote:
> > > > Whatever this patch does renaming does nothing but causing me lots of
> > > > useles (rebasing) efforts. To me ist is simlpy the worst patch of
> > > > this
> > > > year and thanks for blocking me with this. I am really really
> > > > upset!!!
> > >
> > > FWIW you can probably unblock yourself by adding a local copy of the
> > > compatibility bbclass with the warning removed. That will then let you
> > > fix the fallout at a time of your choosing.
> >
> > I thought warning would be relatively harmless... Why would it be
> blocking?
> > Do you want this to be a notice instead?
> >
> >
> > > I was in two minds about the change to be honest but nobody commented
> > > in review and I get really tired of a reputation for saying "no" to
> > > "everything". What probably swung the balance is the ways you can work
> > > around the change at least temporarily.
> >
> > I was also surprised by relative silence in review. Plus, it was in
> > master-next for over a week and nobody complained either...
>
> And to be fair, this is almost right after the release, so is the best
> time
> for such invasive changes - I did wait and held off submitting it for
> several
> months to not disrupt the release process!
> So such overreaction is rather unwarranted...
>
> --
> Denys
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142719): 
https://lists.openembedded.org/g/openembedded-core/message/142719
Mute This Topic: https://lists.openembedded.org/mt/72388036/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Yocto Project Status WW38'20

[Stephen Jolley]

Current Dev Position: YP 3.2 M4

Next Deadline: YP 3.2 M4 Feature Freeze - Now

 

Next Team Meetings:

*   Bug Triage meeting Thursday Sept. 24th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Oct. 6th at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday Sept. 23th at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   M3 rc1 has been built and been through QA. Unfortunately beaglebone
fails to boot so we'll have to go to an rc2. There were 4 other issues
reported by QA too (3 ptest regressions and a bitbake UI issue).
*   We plan to build 3.1.3 imminently
*   The sphinx documentation transition has merged. There is still work
needed to clean up various links and other conversion glitches as well as
areas the manual needs to be brought up to date. Any help much appreciated.
Big thanks to Nico for driving this!
*   The new documentation can be seen at
 https://docs.yoctoproject.org/,
*   One significant potential cause for autobuilder timeout issues has
been identified, potentially the journal on ext4 filesystems was causing IO
prioritisation to fail as the journal only runs with one IO level. We've
modified the journal options on autobuilder workers to be "writeback" to
avoid this. This should reduce autobuilder bitbake timeout issues.
*   Two of the three significant autobuilder issues mentioned last week
remain:

*   qemumips fails with systemd with 256MB memory, it needs 512MB. If we
enable 512MB, we see random hangs. Unless someone can debug and sort the
qemu memory issues, we may end up disabling core-image-sato-sdk and
core-image-full-cmdline for qemumips+systemd
*   networking with qemu images appears to glitch at times (particularly
slower targets such as ltp and qemumips), the session stalls with "no route
to host". We need better serial interrogation to determine the state of qemu
when this happens, it's unclear if qemu/kernel hangs, networking fails or
what is breaking. Help to add this extra debugging would be much
appreciated.

*   There are new autobuilder issues this week, a pseudo bug appears to
be being exposed as well as new intermittent issues, as yet not looked into.
*   We continue to struggle with a number of autobuilder intermittent
bugs. You can see the list of failures we're continuing to see by searching
for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is
proving hard to find anyone interested in helping figure these out and they
significantly hamper our testing.

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M3 is out of QA and will be rebuilt
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.1.3 build date 2020/9/14
*   YP 3.1.3 release date 2020/9/25
*   YP 3.1.4 build date 2020/11/2
*   YP 3.1.4 release date 2020/11/13

 

Tracking Metrics:

*   WDD 2469 (last week 2466) (

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

*   Total patches found: 1268 (last week 1258)
*   Patches in the Pending State: 496 (39%) [last week 496 (39%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

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 Program 

[OE-core] [PATCH] meta: add/fix invalid Upstream-Status tags

[Ross Burton]

Signed-off-by: Ross Burton 
---
 .../systemd/systemd/0001-Use-PREFIX-ROOTPREFIX-correctly.patch  | 2 +-
 ...1-setup.py-pass-missing-libraries-to-Extension-for-mul.patch | 2 +-
 .../qemu/qemu/0001-qemu-Do-not-include-file-if-not-exists.patch | 2 +-
 .../ltp/ltp/0004-guard-mallocopt-with-__GLIBC__.patch   | 2 +-
 ...1-Fix-segfault-on-probing-a-non-PCI-platform-device-on.patch | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/meta/recipes-core/systemd/systemd/0001-Use-PREFIX-ROOTPREFIX-correctly.patch 
b/meta/recipes-core/systemd/systemd/0001-Use-PREFIX-ROOTPREFIX-correctly.patch
index c61941df91..953a33a7a7 100644
--- 
a/meta/recipes-core/systemd/systemd/0001-Use-PREFIX-ROOTPREFIX-correctly.patch
+++ 
b/meta/recipes-core/systemd/systemd/0001-Use-PREFIX-ROOTPREFIX-correctly.patch
@@ -4,7 +4,7 @@ Date: Sun, 16 Aug 2020 16:07:12 +
 Subject: [PATCH] Use PREFIX/ROOTPREFIX correctly
 
 Signed-off-by: Alex Kiernan 
-Upstream-status: Pending [https://github.com/systemd/systemd/issues/16773]
+Upstream-Status: Submitted [https://github.com/systemd/systemd/issues/16773]
 ---
  meson.build  | 1 +
  src/core/systemd.pc.in   | 8 
diff --git 
a/meta/recipes-devtools/python/python3/0001-setup.py-pass-missing-libraries-to-Extension-for-mul.patch
 
b/meta/recipes-devtools/python/python3/0001-setup.py-pass-missing-libraries-to-Extension-for-mul.patch
index d38ed61dd7..ea0af02e72 100644
--- 
a/meta/recipes-devtools/python/python3/0001-setup.py-pass-missing-libraries-to-Extension-for-mul.patch
+++ 
b/meta/recipes-devtools/python/python3/0001-setup.py-pass-missing-libraries-to-Extension-for-mul.patch
@@ -46,7 +46,7 @@ ValueError: semaphore or lock released too many times
 
 And the semaphore issue also caused multiprocessing.Queue().put() hung.
 
-Upstream-Status: Pensing
+Upstream-Status: Pending
 
 Signed-off-by: Hongxu Jia 
 Signed-off-by: Alexander Kanavin 
diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-qemu-Do-not-include-file-if-not-exists.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-qemu-Do-not-include-file-if-not-exists.patch
index 678e059463..d6c0f9ebe9 100644
--- 
a/meta/recipes-devtools/qemu/qemu/0001-qemu-Do-not-include-file-if-not-exists.patch
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-qemu-Do-not-include-file-if-not-exists.patch
@@ -6,7 +6,7 @@ Subject: [PATCH] qemu: Do not include file if not exists
 Script configure checks for if_alg.h and check failed but
 if_alg.h still included.
 
-Upstream-status: Submitted 
[https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07188.html]
+Upstream-Status: Submitted 
[https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07188.html]
 Signed-off-by: Oleksiy Obitotskyy 
 
 [update patch context]
diff --git 
a/meta/recipes-extended/ltp/ltp/0004-guard-mallocopt-with-__GLIBC__.patch 
b/meta/recipes-extended/ltp/ltp/0004-guard-mallocopt-with-__GLIBC__.patch
index e93886c9cd..a187f61f08 100644
--- a/meta/recipes-extended/ltp/ltp/0004-guard-mallocopt-with-__GLIBC__.patch
+++ b/meta/recipes-extended/ltp/ltp/0004-guard-mallocopt-with-__GLIBC__.patch
@@ -7,7 +7,7 @@ mallocopt is not available on non glibc implementations
 
 Signed-off-by: Khem Raj 
 Reviewed-by: Petr Vorel 
-[ Upstream-Status: accepted in 967612c454aea66770b64f69287671037fe895b3 ]
+Upstream-Status: Accepted [967612c454aea66770b64f69287671037fe895b3]
 ---
  utils/benchmark/ebizzy-0.3/ebizzy.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
diff --git 
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Fix-segfault-on-probing-a-non-PCI-platform-device-on.patch
 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Fix-segfault-on-probing-a-non-PCI-platform-device-on.patch
index 7b9e3b4cad..8b687d612d 100644
--- 
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Fix-segfault-on-probing-a-non-PCI-platform-device-on.patch
+++ 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Fix-segfault-on-probing-a-non-PCI-platform-device-on.patch
@@ -10,7 +10,7 @@ case.
 
 Signed-off-by: Eric Anholt 
 
-Upstream-status: Backport 
[https://github.com/freedesktop/xorg-xserver/commit/e50c85f4e]
+Upstream-Status: Backport 
[https://github.com/freedesktop/xorg-xserver/commit/e50c85f4e]
 Signed-off-by: Aníbal Limón 
 ---
  hw/xfree86/common/xf86platformBus.c | 2 +-
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142717): 
https://lists.openembedded.org/g/openembedded-core/message/142717
Mute This Topic: https://lists.openembedded.org/mt/77014330/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 334
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.2", "3.3, "3.99" and "Future", the more pressing/urgent issues
being in "3.2" and then "3.3".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142716): 
https://lists.openembedded.org/g/openembedded-core/message/142716
Mute This Topic: https://lists.openembedded.org/mt/77014141/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] dropbear/openssh: Lower priority of key generation

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 18-09-2020 19:55, Richard Purdie via lists.openembedded.org wrote:

On Fri, 2020-09-18 at 10:45 -0700, Khem Raj wrote:

On 9/17/20 11:00 PM, Richard Purdie wrote:

Where we have images with PAM+systemd, serial login can be
extremely
slow. The load generated by key generation does slow down the rest
of the boot process.


this is a good find. So I wonder if its because we have entropy
starvation. I see that we do enable virtio-rng while launching qemu
so something to look in this area perhaps.

I did check and the virtio rng is alive and well in the image. Its the
CPU usage of the key generation that partly causes the issue.


Another solution is to just have it create smaller keys. The computation 
time seems to grow exponential with the bit count, a 2048 size key can 
take 10 times longer than a 1024 bit key to generate, and a 4096 may 
take 10x that again.


There's been a move to 4096 sizes keys lately, pushing the CPU use even 
further. Unless you're controlling a nuclear power plant or so, that's a 
bit excessive.


--
Mike Looijmans


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142715): 
https://lists.openembedded.org/g/openembedded-core/message/142715
Mute This Topic: https://lists.openembedded.org/mt/76925740/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] pseudo: Remove mismatched inodes from the db

[Richard Purdie]

Currently, where pseudo finds a database entry for an inode but the path
doesn't match, it reuses that database entry metadata. This is causing
real world "corruption" of file attributes.

See [YOCTO #14057] for an example of this.

This can happen when files are deleted outside of pseudo context and the
inode is reused by a new file which pseduo then "sees".

Its possible the opposite could happen, it needs to reuse attributes
but this change would prevent it. As far as I can tell, we don't want
pseuod to reuse these attributes though so this code should be safer
and avoid bugs like the above.

Signed-off-by: Richard Purdie 
---
 .../pseudo/files/delete_mismatches.patch  | 25 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb|  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 meta/recipes-devtools/pseudo/files/delete_mismatches.patch

diff --git a/meta/recipes-devtools/pseudo/files/delete_mismatches.patch 
b/meta/recipes-devtools/pseudo/files/delete_mismatches.patch
new file mode 100644
index 000..59241671767
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/delete_mismatches.patch
@@ -0,0 +1,25 @@
+When we see cases where the inode no longer matches the file path, pseudo 
notices
+but currently reuses the database entry for the file.
+
+Change this to delete the likely stale database entry instead. We're
+seeing bugs where inode reuse for deleted files causes permission corruption.
+(See bug #14057 for example).
+
+Signed-off-by: Richard Purdie 
+Upstream-Status: Pending
+
+Index: git/pseudo.c
+===
+--- git.orig/pseudo.c
 git/pseudo.c
+@@ -705,6 +705,10 @@ pseudo_op(pseudo_msg_t *msg, const char
+   (unsigned long long) 
msg_header.ino,
+   path_by_ino ? path_by_ino : "no 
path",
+   msg->path);
++  if (msg->nlink == 1) {
++  pdb_unlink_file_dev(msg);
++  found_ino = 0;
++  }
+   }
+   }
+   } else {
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 3b623d8bd77..7eb72f0eab3 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -2,6 +2,7 @@ require pseudo.inc
 
 SRC_URI = "git://git.yoctoproject.org/pseudo;branch=oe-core \
file://0001-configure-Prune-PIE-flags.patch \
+   file://delete_mismatches.patch \
file://fallback-passwd \
file://fallback-group \
"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142714): 
https://lists.openembedded.org/g/openembedded-core/message/142714
Mute This Topic: https://lists.openembedded.org/mt/77012533/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] linux-yocto/beaglebone: Switch to sdhci-omap driver

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/.:

541066c5b1e beaglebone: Switch to sdhci-omap driver

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_5.8.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.8.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.8.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.8.bb
index d29c5985cd..bc9040a3d8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.8.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "31fafe701e2adec65d2b2a74a3e592a358915c67"
-SRCREV_meta ?= "a933cb2f91915dceb138775c3878212e228d3eff"
+SRCREV_meta ?= "ffbfe61a194537689c782b20da185e7e4daa9ef9"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.8;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.8.bb
index d32e5d372b..76b61222a8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.8.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine_qemuarm ?= "830cb9af40e856615b7a435a4fac57b748ba56d6"
 SRCREV_machine ?= "31fafe701e2adec65d2b2a74a3e592a358915c67"
-SRCREV_meta ?= "a933cb2f91915dceb138775c3878212e228d3eff"
+SRCREV_meta ?= "ffbfe61a194537689c782b20da185e7e4daa9ef9"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.8.bb
index 9ff1d5da80..8a0b142c00 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.8.bb
@@ -21,7 +21,7 @@ SRCREV_machine_qemux86 ?= 
"31fafe701e2adec65d2b2a74a3e592a358915c67"
 SRCREV_machine_qemux86-64 ?= "31fafe701e2adec65d2b2a74a3e592a358915c67"
 SRCREV_machine_qemumips64 ?= "4faa049b6b7b51c5d12d20c5e9fcf8e0a3ba8d42"
 SRCREV_machine ?= "31fafe701e2adec65d2b2a74a3e592a358915c67"
-SRCREV_meta ?= "a933cb2f91915dceb138775c3878212e228d3eff"
+SRCREV_meta ?= "ffbfe61a194537689c782b20da185e7e4daa9ef9"
 
 # remap qemuarm to qemuarma15 for the 5.8 kernel
 # KMACHINE_qemuarm ?= "qemuarma15"
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142713): 
https://lists.openembedded.org/g/openembedded-core/message/142713
Mute This Topic: https://lists.openembedded.org/mt/77012392/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][RFC] openssh: Start key generation in multi-user mode

[Joshua Watt]

On Tue, Sep 22, 2020, 12:14 AM Khem Raj  wrote:

> On Mon, Sep 21, 2020 at 5:45 PM Joshua Watt  wrote:
> >
> > The sshkeygen uses a lot of CPU time which delays booting (especially in
> > the case where no SSH connection is going to happen), but we also want
> > to be proactive about generating it early so that the first SSH login
> > doesn't have to wait a long time.
> >
> > Starting the key generation when the sockets are created (which is
> > pretty early in the boot process) slows down the boot due to high CPU
> > usage, so as a compromise start it no later than multi-user mode when
> > things have typically settled down. Note that if an SSH connection comes
> > in before multi-user.target is reached, key generation will be started
> > immediately.
> >
> > Signed-off-by: Joshua Watt 
> > ---
> >  meta/recipes-connectivity/openssh/openssh/sshd.socket| 1 -
> >  meta/recipes-connectivity/openssh/openssh/sshd@.service  | 1 +
> >  .../recipes-connectivity/openssh/openssh/sshdgenkeys.service | 5 +
> >  3 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-connectivity/openssh/openssh/sshd.socket
> b/meta/recipes-connectivity/openssh/openssh/sshd.socket
> > index 8d76d62309..12c39b26b5 100644
> > --- a/meta/recipes-connectivity/openssh/openssh/sshd.socket
> > +++ b/meta/recipes-connectivity/openssh/openssh/sshd.socket
> > @@ -1,6 +1,5 @@
> >  [Unit]
> >  Conflicts=sshd.service
> > -Wants=sshdgenkeys.service
> >
> >  [Socket]
> >  ExecStartPre=@BASE_BINDIR@/mkdir -p /var/run/sshd
> > diff --git a/meta/recipes-connectivity/openssh/openssh/sshd@.service
> b/meta/recipes-connectivity/openssh/openssh/sshd@.service
> > index 9d9965e624..40fd38730a 100644
> > --- a/meta/recipes-connectivity/openssh/openssh/sshd@.service
> > +++ b/meta/recipes-connectivity/openssh/openssh/sshd@.service
> > @@ -1,5 +1,6 @@
> >  [Unit]
> >  Description=OpenSSH Per-Connection Daemon
> > +Wants=sshdgenkeys.service
> >  After=sshdgenkeys.service
> >
> >  [Service]
> > diff --git
> a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
> b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
> > index fd81793d51..52617ec275 100644
> > --- a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
> > +++ b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
> > @@ -7,3 +7,8 @@ ExecStart=@LIBEXECDIR@/sshd_check_keys
> >  Type=oneshot
> >  RemainAfterExit=yes
> >  Nice=10
> > +
> > +[Install]
> > +# Start key generation no later than multi-user mode so that we can
> hopefully
> > +# have it generated before the first SSH connection
> > +WantedBy=multi-user.target
>
> This looks better than what we have. Please do something similar for
> dropbearkey.service as well.
> I also wonder if we need After anchor but I would not worry too much about
> it.
>

Yes, it may need After=multi-user.target, otherwise it might start earlier
than you want


> > --
> > 2.28.0
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142712): 
https://lists.openembedded.org/g/openembedded-core/message/142712
Mute This Topic: https://lists.openembedded.org/mt/77004223/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] QA notification for completed autobuilder build (yocto-3.2_M3.rc1)

[Sangeeta Jain]

Hello all,

This is the full report for yocto-3.2_M3.rc1:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

=== Summary 
Beaglebone can not boot up, hence all beaglebone test case are blocked in this 
release.
No high milestone defects.
  
2 new defects and 3 ptest failures are found:

1. The beaglebone can not bootup (BUG id:14052)
This bug blocked all beaglebone test cases.
2. failure in oe-core manual test: test_dependency_explorer_is_launched (BUG 
id:14055)
3. valgrind ptest failed (BUG id:14051)
4. parted ptest failed (BUG id:14050)
5. pango ptest failed (BUG id:14049)

=== Bugs 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14052
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14055
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14051
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14050
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14049 This is the full report 
for yocto-3.2_M3.rc1:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

Thanks,
Sangeeta
> -Original Message-
> From: Pokybuild User 
> Sent: Friday, 18 September, 2020 12:18 AM
> To: yo...@lists.yoctoproject.org
> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> ; Yeoh, Ee Peng ;
> Chan, Aaron Chun Yew ;
> richard.pur...@linuxfoundation.org; akuster...@gmail.com;
> sjolley.yp...@gmail.com; Jain, Sangeeta 
> Subject: QA notification for completed autobuilder build (yocto-3.2_M3.rc1)
> 
> 
> A build flagged for QA (yocto-3.2_M3.rc1) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.2_M3.rc1
> 
> 
> Build hash information:
> 
> bitbake: 29081375659e3dcf1c578cd98ab2c8a2e9f07ca8
> meta-arm: 1f3cf5812c91cdc15f63737bf9b30cce665b2999
> meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
> meta-intel: f7580d72763653893c06e1d9ece7a77c4adb8485
> meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
> meta-mingw: 30a051401c0a73dfff486ca4d0303b434816200f
> oecore: 4e7506882cabf3936f0269c2a98f61c7d595d613
> poky: c6bc20857cd1bdfd25dfc50e413be84d1d12b189
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142711): 
https://lists.openembedded.org/g/openembedded-core/message/142711
Mute This Topic: https://lists.openembedded.org/mt/77009842/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 0/3] Import two python recipes from meta-oe/meta-python

[Richard Purdie]

On Mon, 2020-09-21 at 23:57 -0700, Khem Raj wrote:
> 
> On 9/21/20 5:12 AM, Richard Purdie wrote:
> > We have a slightly pressing situation where the performance test builds
> > are failing after we cleaned up the system installs on those machines
> > and tried to switch over to buildtools entirely.
> > 
> > The issue is the need for jinja2, complicated by the recipe's ptest
> > dependencies. This series imports them with ptest not inherited, the
> > idea being meta-python can bbappend and add the inherit.
> > 
> 
> this seems to make this recipes inferior to what they currently are, 
> IMO, while it solves the OE-Core usecase, it is ignoring wider usecase 
> it has already been addressing all along. So either bring them in full
> or leave some bbappends in meta-python to keep features working for 
> users who are using it.

I discussed this and Tim/Trevor are going to replace the recipe with a
bbappend in meta-oe to ensure that doesn't regress.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142710): 
https://lists.openembedded.org/g/openembedded-core/message/142710
Mute This Topic: https://lists.openembedded.org/mt/76988710/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] systemd: disable xdg-autostart generator by default

[kai]

From: Kai Kang 

xdg-autostart generator is an opt-in feature which is imported by commit:

470c58ba45 systemd: Upgrade v245.6 -> v246

The generator outputs unexpect log info on terminal when log in a image
which includes an X desktop such as Xfce. So add an package config and
disable it by default.

Signed-off-by: Kai Kang 
---
 meta/recipes-core/systemd/systemd_246.2.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_246.2.bb 
b/meta/recipes-core/systemd/systemd_246.2.bb
index 238cd4741f..e555a5718a 100644
--- a/meta/recipes-core/systemd/systemd_246.2.bb
+++ b/meta/recipes-core/systemd/systemd_246.2.bb
@@ -185,6 +185,7 @@ PACKAGECONFIG[userdb] = "-Duserdb=true,-Duserdb=false"
 PACKAGECONFIG[utmp] = "-Dutmp=true,-Dutmp=false"
 PACKAGECONFIG[valgrind] = "-DVALGRIND=1,,valgrind"
 PACKAGECONFIG[vconsole] = 
"-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"
+PACKAGECONFIG[xdg-autostart] = "-Dxdg-autostart=true,-Dxdg-autostart=false"
 # Verify keymaps on locale change
 PACKAGECONFIG[xkbcommon] = "-Dxkbcommon=true,-Dxkbcommon=false,libxkbcommon"
 PACKAGECONFIG[xz] = "-Dxz=true,-Dxz=false,xz"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142708): 
https://lists.openembedded.org/g/openembedded-core/message/142708
Mute This Topic: https://lists.openembedded.org/mt/77008346/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] kea: fix conflict between multilibs

[kai]

From: Kai Kang 

There are conflict of config files between kea and lib32-kea:

| Error: Transaction test error:
|  file /etc/kea/kea-ctrl-agent.conf conflicts between attempted installs of
 lib32-kea-1.7.10-r0.core2_32 and kea-1.7.10-r0.core2_64
|  file /etc/kea/kea-dhcp4.conf conflicts between attempted installs of
 lib32-kea-1.7.10-r0.core2_32 and kea-1.7.10-r0.core2_64

Because they are all commented out, replace the expanded libdir path with
'$libdir' in the config files to avoid conflict.

Signed-off-by: Kai Kang 
---
 .../kea/files/fix-multilib-conflict.patch | 55 +++
 meta/recipes-connectivity/kea/kea_1.7.10.bb   |  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 
meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch

diff --git a/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch 
b/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch
new file mode 100644
index 00..733adf5536
--- /dev/null
+++ b/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch
@@ -0,0 +1,55 @@
+There are conflict of config files between kea and lib32-kea:
+
+| Error: Transaction test error:
+|  file /etc/kea/kea-ctrl-agent.conf conflicts between attempted installs of
+ lib32-kea-1.7.10-r0.core2_32 and kea-1.7.10-r0.core2_64
+|  file /etc/kea/kea-dhcp4.conf conflicts between attempted installs of
+ lib32-kea-1.7.10-r0.core2_32 and kea-1.7.10-r0.core2_64
+
+Because they are all commented out, replace the expanded libdir path with
+'$libdir' in the config files to avoid conflict.
+
+Signed-off-by: Kai Kang 
+---
+ src/bin/keactrl/kea-ctrl-agent.conf.pre | 3 ++-
+ src/bin/keactrl/kea-dhcp4.conf.pre  | 6 --
+ 2 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/src/bin/keactrl/kea-ctrl-agent.conf.pre 
b/src/bin/keactrl/kea-ctrl-agent.conf.pre
+index 211b7ff..d710ec7 100644
+--- a/src/bin/keactrl/kea-ctrl-agent.conf.pre
 b/src/bin/keactrl/kea-ctrl-agent.conf.pre
+@@ -45,7 +45,8 @@
+ // Agent will fail to start.
+ "hooks-libraries": [
+ //  {
+-//  "library": "@libdir@/kea/hooks/control-agent-commands.so",
++//  // Replace $libdir with real library path /usr/lib or /usr/lib64
++//  "library": "$libdir/kea/hooks/control-agent-commands.so",
+ //  "parameters": {
+ //  "param1": "foo"
+ //  }
+diff --git a/src/bin/keactrl/kea-dhcp4.conf.pre 
b/src/bin/keactrl/kea-dhcp4.conf.pre
+index 5f77a32..70ae3d9 100644
+--- a/src/bin/keactrl/kea-dhcp4.conf.pre
 b/src/bin/keactrl/kea-dhcp4.conf.pre
+@@ -252,7 +252,8 @@
+ //  // of all devices serviced by Kea, including their identifiers
+ //  // (like MAC address), their location in the network, times
+ //  // when they were active etc.
+-//  "library": "@libdir@/kea/hooks/libdhcp_legal_log.so"
++//  // Replace $libdir with real library path /usr/lib or /usr/lib64
++//  "library": "$libdir/kea/hooks/libdhcp_legal_log.so"
+ //  "parameters": {
+ //  "path": "/var/lib/kea",
+ //  "base-name": "kea-forensic4"
+@@ -269,7 +270,8 @@
+ //  // of specific options or perhaps even a combination of several
+ //  // options and fields to uniquely identify a client. Those 
scenarios
+ //  // are addressed by the Flexible Identifiers hook application.
+-//  "library": "@libdir@/kea/hooks/libdhcp_flex_id.so",
++//  // Replace $libdir with real library path /usr/lib or /usr/lib64
++//  "library": "$libdir/kea/hooks/libdhcp_flex_id.so",
+ //  "parameters": {
+ //  "identifier-expression": "substring(relay6[0].option[18],0,8)"
+ //  }
diff --git a/meta/recipes-connectivity/kea/kea_1.7.10.bb 
b/meta/recipes-connectivity/kea/kea_1.7.10.bb
index e2560b2399..061f3a7c26 100644
--- a/meta/recipes-connectivity/kea/kea_1.7.10.bb
+++ b/meta/recipes-connectivity/kea/kea_1.7.10.bb
@@ -12,6 +12,7 @@ SRC_URI = "\
 file://kea-dhcp4.service \
 file://kea-dhcp6.service \
 file://kea-dhcp-ddns.service \
+file://fix-multilib-conflict.patch \
 "
 SRC_URI[sha256sum] = 
"4e121f0e58b175a827581c69cb1d60778647049fa47f142940dddc9ce58f3c82"
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142709): 
https://lists.openembedded.org/g/openembedded-core/message/142709
Mute This Topic: https://lists.openembedded.org/mt/77008351/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 0/3] Import two python recipes from meta-oe/meta-python

[Khem Raj]

On 9/21/20 5:12 AM, Richard Purdie wrote:

We have a slightly pressing situation where the performance test builds
are failing after we cleaned up the system installs on those machines
and tried to switch over to buildtools entirely.

The issue is the need for jinja2, complicated by the recipe's ptest
dependencies. This series imports them with ptest not inherited, the
idea being meta-python can bbappend and add the inherit.



this seems to make this recipes inferior to what they currently are, 
IMO, while it solves the OE-Core usecase, it is ignoring wider usecase 
it has already been addressing all along. So either bring them in full
or leave some bbappends in meta-python to keep features working for 
users who are using it.




The alternatives are either to try and solve this on the performace
test machines using horrible hacks and revert my earlier attempted fix
(which is correct but makes the situation worse), or import pytest
over too which we may ultimately end up doing but probably should
do right now?






Richard Purdie (3):
   python3-markupsafe: Import from meta-oe/meta-python
   python3-jinja2: Import from meta-oe/meta-python
   buildtools-tarball: Add python3-jinja2

  meta/conf/distro/include/maintainers.inc  |  2 +
  meta/recipes-core/meta/buildtools-tarball.bb  |  1 +
  .../python/python3-jinja2/run-ptest   |  3 ++
  .../python/python3-jinja2_2.11.2.bb   | 45 +++
  .../python/python3-markupsafe/run-ptest   |  3 ++
  .../python/python3-markupsafe_1.1.1.bb| 28 
  6 files changed, 82 insertions(+)
  create mode 100644 meta/recipes-devtools/python/python3-jinja2/run-ptest
  create mode 100644 meta/recipes-devtools/python/python3-jinja2_2.11.2.bb
  create mode 100644 meta/recipes-devtools/python/python3-markupsafe/run-ptest
  create mode 100644 meta/recipes-devtools/python/python3-markupsafe_1.1.1.bb






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142707): 
https://lists.openembedded.org/g/openembedded-core/message/142707
Mute This Topic: https://lists.openembedded.org/mt/76988710/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-