Re: [OE-core][PATCH 0/4] Import recipes from meta-python

2020-05-15 Thread Steve Sakoman
On Fri, May 15, 2020 at 9:06 AM Richard Purdie
 wrote:
>
> On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote:
> > I see Richard has merged these to master-next, thanks!
> > And thanks Joshua for volunteering to maintain these recipes :)
> > I submitted removal patches to meta-python.
> >
> > So, it is good we are getting this extra dependency resolved in master. The
> > question is - can we get these backported to dunfell, does it qualify?
> >
> > Otherwise Jon wanted to finally branch off meta-arm into dunfell today and
> > we'll have to live with it until gatesgarth.
>
> I put them into -next so we could test them, see if the autobuilder had
> any surprises. Good news is there weren't any.
>
> The question still remains whether this is the best approach or not and
> some people I talked to were not convinced that a consensus had been
> reached.
>
> The question I guess is how widely used is optee and does it warrant
> adding this? Its a little ironic the thing people want is trusted-
> firmware...

I'm seeing a few votes of "yes for dunfell" and no opposition as yet
(at least here on the list).

I support the desire to get rid of a meta-python dependency in bsp
layers so I'm also a yes vote unless someone comes up with a good
reason why we shouldn't.

Steve

> Cheers,
>
> Richard
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138356): 
https://lists.openembedded.org/g/openembedded-core/message/138356
Mute This Topic: https://lists.openembedded.org/mt/74214757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[OE-core] ✗ patchtest: failure for "libsecret: inherit features_ch..." and 1 more

2020-05-15 Thread Patchwork
== Series Details ==

Series: "libsecret: inherit features_ch..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/24179/
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[2/2] webkitgtk, pinentry: require 
gobject-introspection-data in DISTRO_FEATURES when libsecret PACKAGECONFIG is 
enabled
 Issue Commit shortlog is too long [test_shortlog_length] 
  Suggested fixEdit shortlog so that it is 90 characters or less (currently 
114 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138355): 
https://lists.openembedded.org/g/openembedded-core/message/138355
Mute This Topic: https://lists.openembedded.org/mt/74240824/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] webkitgtk, pinentry: require gobject-introspection-data in DISTRO_FEATURES when libsecret PACKAGECONFIG is enabled

2020-05-15 Thread Martin Jansa
* gobject-introspection is mandatory since libsecret upgrade to 0.20.3
* enable libsecret in webkitgtk only when gobject-introspection-data
  is in DISTRO_FEATURES
* drop comment about libsecret being in meta-gnome from pinentry

Signed-off-by: Martin Jansa 
---
 meta/recipes-sato/webkit/webkitgtk_2.28.2.bb| 10 ++
 meta/recipes-support/pinentry/pinentry_1.1.0.bb |  6 +++---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.28.2.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.28.2.bb
index 288c715cc3..51596077b4 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.28.2.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.28.2.bb
@@ -26,7 +26,9 @@ SRC_URI[sha256sum] = 
"b9d23525cfd8d22c37b5d964a9fe9a8ce7583042a2f8d3922e71e6bbc6
 inherit cmake pkgconfig gobject-introspection perlnative features_check 
upstream-version-is-even gtk-doc
 
 ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
-REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 
'opengl', '', d)}"
+REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 
'opengl', '', d)} \
+${@bb.utils.contains('PACKAGECONFIG', 'libsecret', 
'gobject-introspection-data', '', d)} \
+"
 
 CVE_PRODUCT = "webkitgtk webkitgtk\+"
 
@@ -39,10 +41,10 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt 
libgcrypt \
   "
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'webgl opengl', '' ,d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', 'webgl 
gles2' ,d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'webgl opengl', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', 'webgl 
gles2', d)} \
enchant \
-   libsecret \
+   ${@bb.utils.contains('DISTRO_FEATURES', 
'gobject-introspection-data', 'libsecret', '', d)} \
   "
 
 PACKAGECONFIG[wayland] = 
"-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe 
wpebackend-fdo wayland-native"
diff --git a/meta/recipes-support/pinentry/pinentry_1.1.0.bb 
b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
index 8c500dcadc..dc9069b9d5 100644
--- a/meta/recipes-support/pinentry/pinentry_1.1.0.bb
+++ b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
@@ -19,7 +19,9 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
 SRC_URI[md5sum] = "3829315cb0a1e9cedc05ffe6def7a2c6"
 SRC_URI[sha256sum] = 
"68076686fa724a290ea49cdf0d1c0c1500907d1b759a3bcbfbec0293e8f56570"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig features_check
+
+REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG', 'libsecret', 
'gobject-introspection-data', '', d)}"
 
 PACKAGECONFIG ??= "ncurses libcap"
 
@@ -27,8 +29,6 @@ PACKAGECONFIG[ncurses] = "--enable-ncurses  
--with-ncurses-include-dir=${STAGING
 PACKAGECONFIG[libcap] = "--with-libcap, --without-libcap, libcap"
 PACKAGECONFIG[qt] = "--enable-pinentry-qt, --disable-pinentry-qt, 
qtbase-native qtbase"
 PACKAGECONFIG[gtk2] = "--enable-pinentry-gtk2, --disable-pinentry-gtk2, gtk+ 
glib-2.0"
-
-#To use libsecret, add meta-gnome
 PACKAGECONFIG[secret] = "--enable-libsecret, --disable-libsecret, libsecret"
 
 EXTRA_OECONF = " \
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138354): 
https://lists.openembedded.org/g/openembedded-core/message/138354
Mute This Topic: https://lists.openembedded.org/mt/74240622/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] libsecret: inherit features_check

2020-05-15 Thread Martin Jansa
* otherwise REQUIRED_DISTRO_FEATURES doesn't do anything

Signed-off-by: Martin Jansa 
---
 meta/recipes-gnome/libsecret/libsecret_0.20.3.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/libsecret/libsecret_0.20.3.bb 
b/meta/recipes-gnome/libsecret/libsecret_0.20.3.bb
index d3a0c2ff54..8d317c8efc 100644
--- a/meta/recipes-gnome/libsecret/libsecret_0.20.3.bb
+++ b/meta/recipes-gnome/libsecret/libsecret_0.20.3.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=23c2a5e0106b99d75238986559bb5fc6"
 
 GNOMEBASEBUILDCLASS = "meson"
 
-inherit gnomebase gtk-doc vala gobject-introspection manpages
+inherit gnomebase gtk-doc vala gobject-introspection manpages features_check
 
 DEPENDS += "glib-2.0 libgcrypt gettext-native"
 
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138353): 
https://lists.openembedded.org/g/openembedded-core/message/138353
Mute This Topic: https://lists.openembedded.org/mt/74240621/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Richard Purdie
On Sat, 2020-05-16 at 00:33 +0200, Andreas M?ller wrote:
> On Sat, May 16, 2020 at 12:21 AM Denys Dmytriyenko 
> wrote:
> > 
> > Has nothing to do with your name, but with your mail server and
> > DMARC policy.
> > 
> > Many of us are in the same situation, and we learned to live with
> > it, if
> > cannot change it. Moreover, layer maintainers actually have to
> > change names
> > like that back to normal manually before applying patches...
> I consider this a a not acceptable waste of time and not acceptable -
> so I'll go 3. for oe-core.
> 
> @Khem Should I stop contributing in meta-openembedded either due to
> extra efforts caused?

I think there are two potential issues. I suspect the missing Umlaut is
configuration of your groups.io account. I did reply about it once
before and was surprised you hadn't fixed it. If you login in there and
set your name correctly I think that should fix part of the issue.

The "via lists.openembedded.org" is something only you see, not the
rest of us and is due to DMARC and other anti-spam and anti-spoofing
measures most email systems are now requiring. I see the same thing for
my own posts on mailing lists. There is nothing we can do about that,
it depends on the settings for the domain you're sending from and you
won't control the gmail.com policy!

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138352): 
https://lists.openembedded.org/g/openembedded-core/message/138352
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Andreas M?ller
On Sat, May 16, 2020 at 12:21 AM Denys Dmytriyenko  wrote:
>
> On Sat, May 16, 2020 at 12:10:00AM +0200, Andreas Müller wrote:
> > On Fri, May 15, 2020 at 11:59 PM Denys Dmytriyenko  wrote:
> > >
> > > On Fri, May 15, 2020 at 11:52:23PM +0200, Andreas M?ller wrote:
> > > > On Fri, May 15, 2020 at 11:42 PM Andreas M?ller via
> > > > lists.openembedded.org
> > > >  wrote:
> > > > >
> > > > > On Fri, May 15, 2020 at 11:29 PM Andreas M?ller via
> > > > > lists.openembedded.org
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, May 15, 2020 at 10:30 PM Martin Jansa 
> > > > > >  wrote:
> > > > > > >
> > > > > > > This seems to be missing features_check inherit, so that 
> > > > > > > REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.
> > > > > > >
> > > > > > > Will send patch shortly.
> > > > > > Do I miss something? It was never applied
> > > > > >
> > > > > > Andreas
> > > > > Ahh I did not find it due to Umlaut in my name - it was applied
> > > > > indeed. Author is now Andreas M?ller now.
> > > > >
> > > > > Andreas
> > > >
> > > > And to turn this completely off-topic: on each mail I send to the list
> > > > I get an email on extra thread with  'Andreas M?ller via
> > > > lists.openembedded.org' in it's title.
> > >
> > > https://en.wikipedia.org/wiki/DMARC
> > > https://wiki.list.org/DEV/DMARC
> >
> > what do yo expect me to do
>
> Has nothing to do with your name, but with your mail server and DMARC policy.
>
> Many of us are in the same situation, and we learned to live with it, if
> cannot change it. Moreover, layer maintainers actually have to change names
> like that back to normal manually before applying patches...
I consider this a a not acceptable waste of time and not acceptable -
so I'll go 3. for oe-core.

@Khem Should I stop contributing in meta-openembedded either due to
extra efforts caused?

Andreas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138351): 
https://lists.openembedded.org/g/openembedded-core/message/138351
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Denys Dmytriyenko
On Sat, May 16, 2020 at 12:10:00AM +0200, Andreas Müller wrote:
> On Fri, May 15, 2020 at 11:59 PM Denys Dmytriyenko  wrote:
> >
> > On Fri, May 15, 2020 at 11:52:23PM +0200, Andreas M?ller wrote:
> > > On Fri, May 15, 2020 at 11:42 PM Andreas M?ller via
> > > lists.openembedded.org
> > >  wrote:
> > > >
> > > > On Fri, May 15, 2020 at 11:29 PM Andreas M?ller via
> > > > lists.openembedded.org
> > > >  wrote:
> > > > >
> > > > > On Fri, May 15, 2020 at 10:30 PM Martin Jansa 
> > > > >  wrote:
> > > > > >
> > > > > > This seems to be missing features_check inherit, so that 
> > > > > > REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.
> > > > > >
> > > > > > Will send patch shortly.
> > > > > Do I miss something? It was never applied
> > > > >
> > > > > Andreas
> > > > Ahh I did not find it due to Umlaut in my name - it was applied
> > > > indeed. Author is now Andreas M?ller now.
> > > >
> > > > Andreas
> > >
> > > And to turn this completely off-topic: on each mail I send to the list
> > > I get an email on extra thread with  'Andreas M?ller via
> > > lists.openembedded.org' in it's title.
> >
> > https://en.wikipedia.org/wiki/DMARC
> > https://wiki.list.org/DEV/DMARC
> 
> what do yo expect me to do

Has nothing to do with your name, but with your mail server and DMARC policy.

Many of us are in the same situation, and we learned to live with it, if 
cannot change it. Moreover, layer maintainers actually have to change names 
like that back to normal manually before applying patches...


> 1. read gazillion of lines just to sen emails to a mailing list
> 2. change  my name
> 3. stop sending emails
> 
> Since it had worked for decades I prefer 3.
> 
> Andreas
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138350): 
https://lists.openembedded.org/g/openembedded-core/message/138350
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Andreas M?ller
On Fri, May 15, 2020 at 11:59 PM Denys Dmytriyenko  wrote:
>
> On Fri, May 15, 2020 at 11:52:23PM +0200, Andreas M?ller wrote:
> > On Fri, May 15, 2020 at 11:42 PM Andreas M?ller via
> > lists.openembedded.org
> >  wrote:
> > >
> > > On Fri, May 15, 2020 at 11:29 PM Andreas M?ller via
> > > lists.openembedded.org
> > >  wrote:
> > > >
> > > > On Fri, May 15, 2020 at 10:30 PM Martin Jansa  
> > > > wrote:
> > > > >
> > > > > This seems to be missing features_check inherit, so that 
> > > > > REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.
> > > > >
> > > > > Will send patch shortly.
> > > > Do I miss something? It was never applied
> > > >
> > > > Andreas
> > > Ahh I did not find it due to Umlaut in my name - it was applied
> > > indeed. Author is now Andreas M?ller now.
> > >
> > > Andreas
> >
> > And to turn this completely off-topic: on each mail I send to the list
> > I get an email on extra thread with  'Andreas M?ller via
> > lists.openembedded.org' in it's title.
>
> https://en.wikipedia.org/wiki/DMARC
> https://wiki.list.org/DEV/DMARC

what do yo expect me to do

1. read gazillion of lines just to sen emails to a mailing list
2. change  my name
3. stop sending emails

Since it had worked for decades I prefer 3.

Andreas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138349): 
https://lists.openembedded.org/g/openembedded-core/message/138349
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Denys Dmytriyenko
On Fri, May 15, 2020 at 11:52:23PM +0200, Andreas M?ller wrote:
> On Fri, May 15, 2020 at 11:42 PM Andreas M?ller via
> lists.openembedded.org
>  wrote:
> >
> > On Fri, May 15, 2020 at 11:29 PM Andreas M?ller via
> > lists.openembedded.org
> >  wrote:
> > >
> > > On Fri, May 15, 2020 at 10:30 PM Martin Jansa  
> > > wrote:
> > > >
> > > > This seems to be missing features_check inherit, so that 
> > > > REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.
> > > >
> > > > Will send patch shortly.
> > > Do I miss something? It was never applied
> > >
> > > Andreas
> > Ahh I did not find it due to Umlaut in my name - it was applied
> > indeed. Author is now Andreas M?ller now.
> >
> > Andreas
> 
> And to turn this completely off-topic: on each mail I send to the list
> I get an email on extra thread with  'Andreas M?ller via
> lists.openembedded.org' in it's title.

https://en.wikipedia.org/wiki/DMARC
https://wiki.list.org/DEV/DMARC


> This is since we moved to new mailing system (forgot details). Did
> send a mail here and there nothing happened... Should look for a
> different name...
> 
> Andreas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138348): 
https://lists.openembedded.org/g/openembedded-core/message/138348
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Andreas M?ller
On Fri, May 15, 2020 at 11:42 PM Andreas M?ller via
lists.openembedded.org
 wrote:
>
> On Fri, May 15, 2020 at 11:29 PM Andreas M?ller via
> lists.openembedded.org
>  wrote:
> >
> > On Fri, May 15, 2020 at 10:30 PM Martin Jansa  
> > wrote:
> > >
> > > This seems to be missing features_check inherit, so that 
> > > REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.
> > >
> > > Will send patch shortly.
> > Do I miss something? It was never applied
> >
> > Andreas
> Ahh I did not find it due to Umlaut in my name - it was applied
> indeed. Author is now Andreas M?ller now.
>
> Andreas

And to turn this completely off-topic: on each mail I send to the list
I get an email on extra thread with  'Andreas M?ller via
lists.openembedded.org' in it's title.

This is since we moved to new mailing system (forgot details). Did
send a mail here and there nothing happened... Should look for a
different name...

Andreas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138347): 
https://lists.openembedded.org/g/openembedded-core/message/138347
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Andreas M?ller
On Fri, May 15, 2020 at 11:29 PM Andreas M?ller via
lists.openembedded.org
 wrote:
>
> On Fri, May 15, 2020 at 10:30 PM Martin Jansa  wrote:
> >
> > This seems to be missing features_check inherit, so that 
> > REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.
> >
> > Will send patch shortly.
> Do I miss something? It was never applied
>
> Andreas
Ahh I did not find it due to Umlaut in my name - it was applied
indeed. Author is now Andreas M?ller now.

Andreas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138346): 
https://lists.openembedded.org/g/openembedded-core/message/138346
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Andreas M?ller
On Fri, May 15, 2020 at 10:30 PM Martin Jansa  wrote:
>
> This seems to be missing features_check inherit, so that 
> REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.
>
> Will send patch shortly.
Do I miss something? It was never applied

Andreas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138345): 
https://lists.openembedded.org/g/openembedded-core/message/138345
Mute This Topic: https://lists.openembedded.org/mt/73385682/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 2/2] libsecret: upgrade 0.20.1 -> 0.20.3 / port to meson

2020-05-15 Thread Martin Jansa
This seems to be missing features_check inherit, so
that REQUIRED_DISTRO_FEATURES doesn't prevent it failing in my builds.

Will send patch shortly.

On Thu, Apr 30, 2020 at 11:42 PM Andreas M?ller 
wrote:

> From [1]:
>
> 0.20.3
>  * secret-file-backend: Fix use-after-free in flatpak [!52]
>  * docs: Add man subdir only if manpage is enabled [!51]
>
> From [2]:
>
> 0.20.2
>  * secret-file-collection: force little-endian in GVariant [!49, #42]
>  * Prefer g_info() over g_message() [!48, #40]
>  * meson: Don't specify shared_library() [!47]
>  * docs: Make sure to set install: true [!46]
>
> [1]
> http://ftp.gnome.org/pub/gnome/sources/libsecret/0.20/libsecret-0.20.3.news
> [2]
> http://ftp.gnome.org/pub/gnome/sources/libsecret/0.20/libsecret-0.20.2.news
>
> Signed-off-by: Andreas Müller 
> ---
>  ...ibsecret_0.20.1.bb => libsecret_0.20.3.bb} | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
>  rename meta/recipes-gnome/libsecret/{libsecret_0.20.1.bb =>
> libsecret_0.20.3.bb} (63%)
>
> diff --git a/meta/recipes-gnome/libsecret/libsecret_0.20.1.bb
> b/meta/recipes-gnome/libsecret/libsecret_0.20.3.bb
> similarity index 63%
> rename from meta/recipes-gnome/libsecret/libsecret_0.20.1.bb
> rename to meta/recipes-gnome/libsecret/libsecret_0.20.3.bb
> index 72511af02d..d3a0c2ff54 100644
> --- a/meta/recipes-gnome/libsecret/libsecret_0.20.1.bb
> +++ b/meta/recipes-gnome/libsecret/libsecret_0.20.3.bb
> @@ -7,21 +7,24 @@ LICENSE = "LGPLv2.1"
>  BUGTRACKER = "https://gitlab.gnome.org/GNOME/libsecret/issues;
>  LIC_FILES_CHKSUM = "file://COPYING;md5=23c2a5e0106b99d75238986559bb5fc6"
>
> +GNOMEBASEBUILDCLASS = "meson"
> +
>  inherit gnomebase gtk-doc vala gobject-introspection manpages
>
>  DEPENDS += "glib-2.0 libgcrypt gettext-native"
>
> -PACKAGECONFIG[manpages] = "--enable-manpages, --disable-manpages,
> libxslt-native xmlto-native"
> +SRC_URI[archive.md5sum] = "47c3fdfeb111a87b509ad271e4a6f496"
> +SRC_URI[archive.sha256sum] =
> "4fcb3c56f8ac4ab9c75b66901fb0104ec7f22aa9a012315a14c0d6dffa5290e4"
> +
> +GTKDOC_MESON_OPTION = 'gtk_doc'
>
> -SRC_URI[archive.md5sum] = "d2dd660a8d502099317bc8af9f30302e"
> -SRC_URI[archive.sha256sum] =
> "57f73e94ec6263a17a077fb809cf8cf424637a897a7f15b4eec42ce4aef52447"
> +# gobject-introspection is mandatory and cannot be configured
> +REQUIRED_DISTRO_FEATURES = "gobject-introspection-data"
> +UNKNOWN_CONFIGURE_WHITELIST_append = " introspection"
> +
> +PACKAGECONFIG[manpages] = "-Dmanpage=true,-Dmanpage=false,libxslt-native
> xmlto-native"
>
>  # http://errors.yoctoproject.org/Errors/Details/20228/
>  ARM_INSTRUCTION_SET_armv4 = "arm"
>  ARM_INSTRUCTION_SET_armv5 = "arm"
>  ARM_INSTRUCTION_SET_armv6 = "arm"
> -
> -# vapigen.m4 bundled with the tarball does not yet have our
> cross-compilation fixes
> -do_configure_prepend() {
> -rm -f ${S}/build/m4/vapigen.m4
> -}
> --
> 2.21.1
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138344): 
https://lists.openembedded.org/g/openembedded-core/message/138344
Mute This Topic: https://lists.openembedded.org/mt/73385682/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/4] Import recipes from meta-python

2020-05-15 Thread Andrey Zhizhikin
On Fri, May 15, 2020 at 9:26 PM Denys Dmytriyenko  wrote:
>
> On Fri, May 15, 2020 at 02:12:55PM -0500, Joshua Watt wrote:
> >
> > On 5/15/20 2:05 PM, Richard Purdie wrote:
> > >On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote:
> > >>I see Richard has merged these to master-next, thanks!
> > >>And thanks Joshua for volunteering to maintain these recipes :)
> > >>I submitted removal patches to meta-python.
> > >>
> > >>So, it is good we are getting this extra dependency resolved in master. 
> > >>The
> > >>question is - can we get these backported to dunfell, does it qualify?
> > >>
> > >>Otherwise Jon wanted to finally branch off meta-arm into dunfell today and
> > >>we'll have to live with it until gatesgarth.
> > >I put them into -next so we could test them, see if the autobuilder had
> > >any surprises. Good news is there weren't any.
> > >
> > >The question still remains whether this is the best approach or not and
> > >some people I talked to were not convinced that a consensus had been
> > >reached.
> > >
> > >The question I guess is how widely used is optee and does it warrant
> > >adding this? Its a little ironic the thing people want is trusted-
> > >firmware...
> >
> > FWIW, after having gone through the exercise of pulling in TF-A into
> > qemuarm64, I think I've been convinced that op-tee and TF-A belong
> > together since they are sometimes tightly integrated together
> > (something I didn't realize before). As such, having both in the
> > same layer makes sense. Even if TF-A was in oe-core, you'd probably
> > want op-tee also, which means the python modules would have to be
> > there anyway. I think we can still have the discussion about moving
> > the whole lot over there, but we don't need to do that now, and
> > moving the python recipes at least cuts out the meta-python
> > dependency.
> >
> > My last concern was testing of optee, since there was no platform
> > that could build it by default,
>
> Many TI platforms do. All our recent Aarch64 platforms (K3 family) use
> TF-A and OP-TEE by default and require them both to boot.

Just FYI: NXP i.MX8[M] series uses OP-TEE and it is also required to
boot the SoC.

>
> Even many of our Armv7 platforms use OP-TEE, but you'd need a special "secure"
> version of the platform, and those are not available to the broad-market.
>
>
> > but I fixed that by implemented
> > support for a qemuarm64-based machine that's defined in meta-arm
> > which uses TF-A + optee + u-boot and can successful boot using TF-A
> > and passes the op-tee unit tests, so I don't have any concern about
> > that anymore.
>
> That's great for testing meta-arm components w/o requiring any specialized
> platforms!
>
> --
> Denys
> 



-- 
Regards,
Andrey.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138343): 
https://lists.openembedded.org/g/openembedded-core/message/138343
Mute This Topic: https://lists.openembedded.org/mt/74214757/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/4] Import recipes from meta-python

2020-05-15 Thread Khem Raj



On 5/15/20 12:12 PM, Joshua Watt wrote:


On 5/15/20 2:05 PM, Richard Purdie wrote:

On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote:

I see Richard has merged these to master-next, thanks!
And thanks Joshua for volunteering to maintain these recipes :)
I submitted removal patches to meta-python.

So, it is good we are getting this extra dependency resolved in 
master. The

question is - can we get these backported to dunfell, does it qualify?

Otherwise Jon wanted to finally branch off meta-arm into dunfell 
today and

we'll have to live with it until gatesgarth.

I put them into -next so we could test them, see if the autobuilder had
any surprises. Good news is there weren't any.

The question still remains whether this is the best approach or not and
some people I talked to were not convinced that a consensus had been
reached.

The question I guess is how widely used is optee and does it warrant
adding this? Its a little ironic the thing people want is trusted-
firmware...


FWIW, after having gone through the exercise of pulling in TF-A into 
qemuarm64, I think I've been convinced that op-tee and TF-A belong 
together since they are sometimes tightly integrated together (something 
I didn't realize before). As such, having both in the same layer makes 
sense. Even if TF-A was in oe-core, you'd probably want op-tee also, 
which means the python modules would have to be there anyway. I think we 
can still have the discussion about moving the whole lot over there, but 
we don't need to do that now, and moving the python recipes at least 
cuts out the meta-python dependency.


My last concern was testing of optee, since there was no platform that 
could build it by default, but I fixed that by implemented support for a 
qemuarm64-based machine that's defined in meta-arm which uses TF-A + 
optee + u-boot and can successful boot using TF-A and passes the op-tee 
unit tests, so I don't have any concern about that anymore.




I think getting oe-core qemuarm64 boot with uboot+TF-A as an option 
sounds good, and if thats more common solution that armv8 devices are 
following then perhaps would make sense to have this tested in core too. 
But I guess that can be ironed out. As such python deps I think are good 
for dunfell too, we have to ensure meta-python removal happens in 
dunfell as well.




Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138342): 
https://lists.openembedded.org/g/openembedded-core/message/138342
Mute This Topic: https://lists.openembedded.org/mt/74214757/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/4] Import recipes from meta-python

2020-05-15 Thread Denys Dmytriyenko
On Fri, May 15, 2020 at 02:12:55PM -0500, Joshua Watt wrote:
> 
> On 5/15/20 2:05 PM, Richard Purdie wrote:
> >On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote:
> >>I see Richard has merged these to master-next, thanks!
> >>And thanks Joshua for volunteering to maintain these recipes :)
> >>I submitted removal patches to meta-python.
> >>
> >>So, it is good we are getting this extra dependency resolved in master. The
> >>question is - can we get these backported to dunfell, does it qualify?
> >>
> >>Otherwise Jon wanted to finally branch off meta-arm into dunfell today and
> >>we'll have to live with it until gatesgarth.
> >I put them into -next so we could test them, see if the autobuilder had
> >any surprises. Good news is there weren't any.
> >
> >The question still remains whether this is the best approach or not and
> >some people I talked to were not convinced that a consensus had been
> >reached.
> >
> >The question I guess is how widely used is optee and does it warrant
> >adding this? Its a little ironic the thing people want is trusted-
> >firmware...
> 
> FWIW, after having gone through the exercise of pulling in TF-A into
> qemuarm64, I think I've been convinced that op-tee and TF-A belong
> together since they are sometimes tightly integrated together
> (something I didn't realize before). As such, having both in the
> same layer makes sense. Even if TF-A was in oe-core, you'd probably
> want op-tee also, which means the python modules would have to be
> there anyway. I think we can still have the discussion about moving
> the whole lot over there, but we don't need to do that now, and
> moving the python recipes at least cuts out the meta-python
> dependency.
> 
> My last concern was testing of optee, since there was no platform
> that could build it by default,

Many TI platforms do. All our recent Aarch64 platforms (K3 family) use 
TF-A and OP-TEE by default and require them both to boot.

Even many of our Armv7 platforms use OP-TEE, but you'd need a special "secure" 
version of the platform, and those are not available to the broad-market.


> but I fixed that by implemented
> support for a qemuarm64-based machine that's defined in meta-arm
> which uses TF-A + optee + u-boot and can successful boot using TF-A
> and passes the op-tee unit tests, so I don't have any concern about
> that anymore.

That's great for testing meta-arm components w/o requiring any specialized 
platforms!

-- 
Denys
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138341): 
https://lists.openembedded.org/g/openembedded-core/message/138341
Mute This Topic: https://lists.openembedded.org/mt/74214757/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/4] Import recipes from meta-python

2020-05-15 Thread Joshua Watt


On 5/15/20 2:05 PM, Richard Purdie wrote:

On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote:

I see Richard has merged these to master-next, thanks!
And thanks Joshua for volunteering to maintain these recipes :)
I submitted removal patches to meta-python.

So, it is good we are getting this extra dependency resolved in master. The
question is - can we get these backported to dunfell, does it qualify?

Otherwise Jon wanted to finally branch off meta-arm into dunfell today and
we'll have to live with it until gatesgarth.

I put them into -next so we could test them, see if the autobuilder had
any surprises. Good news is there weren't any.

The question still remains whether this is the best approach or not and
some people I talked to were not convinced that a consensus had been
reached.

The question I guess is how widely used is optee and does it warrant
adding this? Its a little ironic the thing people want is trusted-
firmware...


FWIW, after having gone through the exercise of pulling in TF-A into 
qemuarm64, I think I've been convinced that op-tee and TF-A belong 
together since they are sometimes tightly integrated together (something 
I didn't realize before). As such, having both in the same layer makes 
sense. Even if TF-A was in oe-core, you'd probably want op-tee also, 
which means the python modules would have to be there anyway. I think we 
can still have the discussion about moving the whole lot over there, but 
we don't need to do that now, and moving the python recipes at least 
cuts out the meta-python dependency.


My last concern was testing of optee, since there was no platform that 
could build it by default, but I fixed that by implemented support for a 
qemuarm64-based machine that's defined in meta-arm which uses TF-A + 
optee + u-boot and can successful boot using TF-A and passes the op-tee 
unit tests, so I don't have any concern about that anymore.




Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138340): 
https://lists.openembedded.org/g/openembedded-core/message/138340
Mute This Topic: https://lists.openembedded.org/mt/74214757/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/4] Import recipes from meta-python

2020-05-15 Thread Richard Purdie
On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote:
> I see Richard has merged these to master-next, thanks!
> And thanks Joshua for volunteering to maintain these recipes :)
> I submitted removal patches to meta-python.
> 
> So, it is good we are getting this extra dependency resolved in master. The 
> question is - can we get these backported to dunfell, does it qualify?
> 
> Otherwise Jon wanted to finally branch off meta-arm into dunfell today and 
> we'll have to live with it until gatesgarth.

I put them into -next so we could test them, see if the autobuilder had
any surprises. Good news is there weren't any.

The question still remains whether this is the best approach or not and
some people I talked to were not convinced that a consensus had been
reached.

The question I guess is how widely used is optee and does it warrant
adding this? Its a little ironic the thing people want is trusted-
firmware...

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138339): 
https://lists.openembedded.org/g/openembedded-core/message/138339
Mute This Topic: https://lists.openembedded.org/mt/74214757/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/4] Import recipes from meta-python

2020-05-15 Thread Denys Dmytriyenko
I see Richard has merged these to master-next, thanks!
And thanks Joshua for volunteering to maintain these recipes :)
I submitted removal patches to meta-python.

So, it is good we are getting this extra dependency resolved in master. The 
question is - can we get these backported to dunfell, does it qualify?

Otherwise Jon wanted to finally branch off meta-arm into dunfell today and 
we'll have to live with it until gatesgarth.

-- 
Denys


On Thu, May 14, 2020 at 04:04:54PM -0500, Joshua Watt wrote:
> Imports and upgrades pycryptodome, pycryptodomex, and pyelftools from
> meta-python.  These recipes are commonly used by other layers (e.g.
> meta-arm) so putting them in oe-core reduces layer dependencies.
> 
> Joshua Watt (4):
>   pycryptodome: Import from meta-python
>   pyelftools: Import from meta-python
>   python3-pycryptodome(x): Upgrade 3.9.4 -> 3.9.7
>   python3-pyelftools: Upgrade 0.25 -> 0.26
> 
>  meta/conf/distro/include/maintainers.inc  |  5 +++-
>  .../python/python-pycryptodome.inc| 26 +++
>  .../python/python3-pycryptodome_3.9.7.bb  |  5 
>  .../python/python3-pycryptodomex_3.9.7.bb |  9 +++
>  .../python/python3-pyelftools_0.26.bb | 14 ++
>  5 files changed, 58 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/python/python-pycryptodome.inc
>  create mode 100644 meta/recipes-devtools/python/python3-pycryptodome_3.9.7.bb
>  create mode 100644 
> meta/recipes-devtools/python/python3-pycryptodomex_3.9.7.bb
>  create mode 100644 meta/recipes-devtools/python/python3-pyelftools_0.26.bb
> 
> -- 
> 2.17.1
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138338): 
https://lists.openembedded.org/g/openembedded-core/message/138338
Mute This Topic: https://lists.openembedded.org/mt/74214757/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] OpenEmbedded Happy Hour

2020-05-15 Thread Daniel D?az
Hello!

On Fri, 15 May 2020 at 10:56, Philip Balister  wrote:
> I've made a wiki page to track these:
> https://www.openembedded.org/wiki/Happy_Hours
> Then next one is scheduled for 2100 UTC on May 27.

Ah, just in time to watch live SpaceX's launch:
https://blogs.nasa.gov/commercialcrew/

Greetings!

Daniel Díaz
daniel.d...@linaro.org
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138337): 
https://lists.openembedded.org/g/openembedded-core/message/138337
Mute This Topic: https://lists.openembedded.org/mt/74230229/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[OE-core] OpenEmbedded Happy Hour

2020-05-15 Thread Philip Balister
I've made a wiki page to track these:

https://www.openembedded.org/wiki/Happy_Hours

Then next one is scheduled for 2100 UTC on May 27. This is late evening
for Europe and morning for New Zealand, so hopefully we see some
different faces. The meeting info is on the wiki page.

There is no set agenda, so bring some projects to talk about with the
community.


Philip
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138336): 
https://lists.openembedded.org/g/openembedded-core/message/138336
Mute This Topic: https://lists.openembedded.org/mt/74230229/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[OE-core] ✗ patchtest: failure for valgrind: Backport upstream patch to fix __getauxval needs

2020-05-15 Thread Patchwork
== Series Details ==

Series: valgrind: Backport upstream patch to fix __getauxval needs
Revision: 1
URL   : https://patchwork.openembedded.org/series/24174/
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 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 ce6c50ea68)



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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138335): 
https://lists.openembedded.org/g/openembedded-core/message/138335
Mute This Topic: https://lists.openembedded.org/mt/74229690/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] layer.conf: Move to gatesgarth naming

2020-05-15 Thread Richard Purdie
We're still compatible with dunfell from the core perspective so
that is left for compatibility (probably for the next week or two).

Signed-off-by: Richard Purdie 
---
 meta-selftest/conf/layer.conf | 2 +-
 meta-skeleton/conf/layer.conf | 2 +-
 meta/conf/layer.conf  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-selftest/conf/layer.conf b/meta-selftest/conf/layer.conf
index a4bd461c3e4..37570aa833e 100644
--- a/meta-selftest/conf/layer.conf
+++ b/meta-selftest/conf/layer.conf
@@ -9,4 +9,4 @@ BBFILE_COLLECTIONS += "selftest"
 BBFILE_PATTERN_selftest = "^${LAYERDIR}/"
 BBFILE_PRIORITY_selftest = "5"
 
-LAYERSERIES_COMPAT_selftest = "dunfell"
+LAYERSERIES_COMPAT_selftest = "gatesgarth"
diff --git a/meta-skeleton/conf/layer.conf b/meta-skeleton/conf/layer.conf
index 5e449a4e4af..cea5c74f8b6 100644
--- a/meta-skeleton/conf/layer.conf
+++ b/meta-skeleton/conf/layer.conf
@@ -14,4 +14,4 @@ LAYERVERSION_skeleton = "1"
 
 LAYERDEPENDS_skeleton = "core"
 
-LAYERSERIES_COMPAT_skeleton = "dunfell"
+LAYERSERIES_COMPAT_skeleton = "gatesgarth"
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index f03eb485a38..da93d64e0ab 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -7,12 +7,12 @@ BBFILE_COLLECTIONS += "core"
 BBFILE_PATTERN_core = "^${LAYERDIR}/"
 BBFILE_PRIORITY_core = "5"
 
-LAYERSERIES_CORENAMES = "dunfell"
+LAYERSERIES_CORENAMES = "dunfell gatesgarth"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers
 LAYERVERSION_core = "11"
-LAYERSERIES_COMPAT_core = "dunfell"
+LAYERSERIES_COMPAT_core = "gatesgarth"
 
 BBLAYERS_LAYERINDEX_NAME_core = "openembedded-core"
 
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138334): 
https://lists.openembedded.org/g/openembedded-core/message/138334
Mute This Topic: https://lists.openembedded.org/mt/74229686/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] ghostscript: Remove leftover file

2020-05-15 Thread Richard Purdie
This should have been removed in a previous change but was accidentally
left behind and points at an invalid directory.

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/ghostscript/ghostscript/i686 | 1 -
 1 file changed, 1 deletion(-)
 delete mode 12 meta/recipes-extended/ghostscript/ghostscript/i686

diff --git a/meta/recipes-extended/ghostscript/ghostscript/i686 
b/meta/recipes-extended/ghostscript/ghostscript/i686
deleted file mode 12
index 87aaca5903f..000
--- a/meta/recipes-extended/ghostscript/ghostscript/i686
+++ /dev/null
@@ -1 +0,0 @@
-i586
\ No newline at end of file
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138333): 
https://lists.openembedded.org/g/openembedded-core/message/138333
Mute This Topic: https://lists.openembedded.org/mt/74229685/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] valgrind: Backport upstream patch to fix __getauxval needs

2020-05-15 Thread Khem Raj
Drop disabling outline-atomics since that was added to fix this issue in
particular

Signed-off-by: Khem Raj 
---
 ...d-needs-__getauxval-for-linking-with.patch | 144 ++
 .../valgrind/valgrind_3.15.0.bb   |   3 +-
 2 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-gcc10-arm64-build-needs-__getauxval-for-linking-with.patch

diff --git 
a/meta/recipes-devtools/valgrind/valgrind/0001-gcc10-arm64-build-needs-__getauxval-for-linking-with.patch
 
b/meta/recipes-devtools/valgrind/valgrind/0001-gcc10-arm64-build-needs-__getauxval-for-linking-with.patch
new file mode 100644
index 00..9afa7f6a55
--- /dev/null
+++ 
b/meta/recipes-devtools/valgrind/valgrind/0001-gcc10-arm64-build-needs-__getauxval-for-linking-with.patch
@@ -0,0 +1,144 @@
+From abbc0761fa0349d49b10dc8c0f10af6bc0578c40 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard 
+Date: Tue, 12 May 2020 16:58:36 +0200
+Subject: [PATCH 1/2] gcc10 arm64 build needs __getauxval for linking with
+ libgcc
+
+Provide a new library libgcc-sup-.a that contains symbols
+needed by libgcc. This needs to be linked after -lgcc to provide
+any symbols missing which would normally be provided by glibc.
+At the moment this only provides __getauxval on arm64 linux.
+
+https://bugs.kde.org/show_bug.cgi?id=421321
+
+Signed-off-by: Khem Raj 
+Upstream-Status: Backport 
[https://sourceware.org/git/?p=valgrind.git;a=commit;h=abbc0761fa0349d49b10dc8c0f10af6bc0578c40]
+
+---
+ Makefile.tool.am |  3 +-
+ coregrind/Makefile.am| 26 +
+ coregrind/m_libgcc_sup.c | 61 
+ 3 files changed, 89 insertions(+), 1 deletion(-)
+ create mode 100644 coregrind/m_libgcc_sup.c
+
+diff --git a/Makefile.tool.am b/Makefile.tool.am
+index cc2fa0ee6..2bf90de5d 100644
+--- a/Makefile.tool.am
 b/Makefile.tool.am
+@@ -17,7 +17,8 @@ TOOL_DEPENDENCIES_@VGCONF_PLATFORM_SEC_CAPS@ = \
+ endif
+ 
+ 
+-TOOL_LDADD_COMMON = -lgcc
++TOOL_LDADD_COMMON = -lgcc \
++  $(top_builddir)/coregrind/libgcc-sup-@VGCONF_ARCH_PRI@-@VGCONF_OS@.a
+ TOOL_LDADD_@VGCONF_PLATFORM_PRI_CAPS@ = \
+   $(TOOL_DEPENDENCIES_@VGCONF_PLATFORM_PRI_CAPS@) $(TOOL_LDADD_COMMON)
+ if VGCONF_HAVE_PLATFORM_SEC
+diff --git a/coregrind/Makefile.am b/coregrind/Makefile.am
+index 6a1a925fb..1753fb633 100644
+--- a/coregrind/Makefile.am
 b/coregrind/Makefile.am
+@@ -542,6 +542,32 @@ libcoregrind_@VGCONF_ARCH_SEC@_@VGCONF_OS@_a_DEPENDENCIES 
= \
+ libnolto_coregrind-@VGCONF_ARCH_SEC@-@VGCONF_OS@.a
+ endif
+ 
++#
++# libgcc-sup-.a
++# Special supplemental library for functions normally supplied by glibc
++# used by libgcc.
++#
++
++pkglib_LIBRARIES  += libgcc-sup-@VGCONF_ARCH_PRI@-@VGCONF_OS@.a
++if VGCONF_HAVE_PLATFORM_SEC
++pkglib_LIBRARIES += libgcc-sup-@VGCONF_ARCH_SEC@-@VGCONF_OS@.a
++endif
++
++libgcc_sup_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
++  m_libgcc_sup.c
++libgcc_sup_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CPPFLAGS = \
++  $(AM_CPPFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
++libgcc_sup_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CFLAGS = \
++  $(AM_CFLAGS_PSO_@VGCONF_PLATFORM_PRI_CAPS@)
++if VGCONF_HAVE_PLATFORM_SEC
++libgcc_sup_@VGCONF_ARCH_SEC@_@VGCONF_OS@_a_SOURCES = \
++  m_libgcc_sup.c
++libgcc_sup_@VGCONF_ARCH_SEC@_@VGCONF_OS@_a_CPPFLAGS = \
++  $(AM_CPPFLAGS_@VGCONF_PLATFORM_SEC_CAPS@)
++libgcc_sup_@VGCONF_ARCH_SEC@_@VGCONF_OS@_a_CFLAGS = \
++  $(AM_CFLAGS_PSO_@VGCONF_PLATFORM_SEC_CAPS@)
++endif
++
+ #
+ # libreplacemalloc_toolpreload-.a
+ #
+diff --git a/coregrind/m_libgcc_sup.c b/coregrind/m_libgcc_sup.c
+new file mode 100644
+index 0..e29325459
+--- /dev/null
 b/coregrind/m_libgcc_sup.c
+@@ -0,0 +1,61 @@
++/* -*- mode: C; c-basic-offset: 3; -*- */
++
++/**/
++/*--- Supplemental functions for libgcc normally provided by glibc ---*/
++/**/
++
++/*
++   This file is part of Valgrind, a dynamic binary instrumentation
++   framework.
++
++   Copyright (C) 2020 Mark Wielaard
++  m...@klomp.org
++
++   This program is free software; you can redistribute it and/or
++   modify it under the terms of the GNU General Public License as
++   published by the Free Software Foundation; either version 2 of the
++   License, or (at your option) any later version.
++
++   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 

[OE-core][zeus][PATCH] wireless-regdb: Upgrade 2019.06.03 -> 2020.04.29

2020-05-15 Thread Adrian Bunk
From: Adrian Bunk 

(From OE-Core rev: 5b71a3f3d1bca6b52f53b97971131a6771618420)

Signed-off-by: Adrian Bunk 
Signed-off-by: Richard Purdie 
---
 ...reless-regdb_2019.06.03.bb => wireless-regdb_2020.04.29.bb} | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
 rename meta/recipes-kernel/wireless-regdb/{wireless-regdb_2019.06.03.bb => 
wireless-regdb_2020.04.29.bb} (91%)

diff --git a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2019.06.03.bb 
b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2020.04.29.bb
similarity index 91%
rename from meta/recipes-kernel/wireless-regdb/wireless-regdb_2019.06.03.bb
rename to meta/recipes-kernel/wireless-regdb/wireless-regdb_2020.04.29.bb
index 9076d94601..a5827b9ef0 100644
--- a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2019.06.03.bb
+++ b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2020.04.29.bb
@@ -5,8 +5,7 @@ LICENSE = "ISC"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=07c4f6dea3845b02a18dc00c8c87699c"
 
 SRC_URI = "https://www.kernel.org/pub/software/network/${BPN}/${BP}.tar.xz;
-SRC_URI[md5sum] = "4b5ba3f089db7fdb7b9daae6a7c1f2cb"
-SRC_URI[sha256sum] = 
"cd917ed86b63ce8d93947979f1f18948f03a4ac0ad89ec25227b36ac00dc54bf"
+SRC_URI[sha256sum] = 
"89fd031aed5977c219a71501e144375a10e7c90d1005d5d086ea7972886a2c7a"
 
 inherit bin_package allarch
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138331): 
https://lists.openembedded.org/g/openembedded-core/message/138331
Mute This Topic: https://lists.openembedded.org/mt/74228672/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[OE-core][dunfell][PATCH] wireless-regdb: Upgrade 2019.06.03 -> 2020.04.29

2020-05-15 Thread Adrian Bunk
From: Adrian Bunk 

(From OE-Core rev: 5b71a3f3d1bca6b52f53b97971131a6771618420)

Signed-off-by: Adrian Bunk 
Signed-off-by: Richard Purdie 
---
 ...reless-regdb_2019.06.03.bb => wireless-regdb_2020.04.29.bb} | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
 rename meta/recipes-kernel/wireless-regdb/{wireless-regdb_2019.06.03.bb => 
wireless-regdb_2020.04.29.bb} (91%)

diff --git a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2019.06.03.bb 
b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2020.04.29.bb
similarity index 91%
rename from meta/recipes-kernel/wireless-regdb/wireless-regdb_2019.06.03.bb
rename to meta/recipes-kernel/wireless-regdb/wireless-regdb_2020.04.29.bb
index 9076d94601..a5827b9ef0 100644
--- a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2019.06.03.bb
+++ b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2020.04.29.bb
@@ -5,8 +5,7 @@ LICENSE = "ISC"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=07c4f6dea3845b02a18dc00c8c87699c"
 
 SRC_URI = "https://www.kernel.org/pub/software/network/${BPN}/${BP}.tar.xz;
-SRC_URI[md5sum] = "4b5ba3f089db7fdb7b9daae6a7c1f2cb"
-SRC_URI[sha256sum] = 
"cd917ed86b63ce8d93947979f1f18948f03a4ac0ad89ec25227b36ac00dc54bf"
+SRC_URI[sha256sum] = 
"89fd031aed5977c219a71501e144375a10e7c90d1005d5d086ea7972886a2c7a"
 
 inherit bin_package allarch
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138330): 
https://lists.openembedded.org/g/openembedded-core/message/138330
Mute This Topic: https://lists.openembedded.org/mt/74228663/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 3/4] lttng-tools: upgrade to 2.12.0

2020-05-15 Thread Ovidiu Panait
Upgrade lttng-tools 2.11.2 -> 2.12.0:
* drop x32 patch, as it was merged upstream
* License-Update: licenses were moved under LICENSES directory and changed in
  upstream commit [1]

[1] 
https://github.com/lttng/lttng-tools/commit/ab5be9fa2eb5ba9600a82cd18fd3cfcbac69169a

Signed-off-by: Ovidiu Panait 
---
 .../lttng/lttng-tools/x32.patch   | 36 ---
 ...-tools_2.11.2.bb => lttng-tools_2.12.0.bb} | 11 +++---
 2 files changed, 5 insertions(+), 42 deletions(-)
 delete mode 100644 meta/recipes-kernel/lttng/lttng-tools/x32.patch
 rename meta/recipes-kernel/lttng/{lttng-tools_2.11.2.bb => 
lttng-tools_2.12.0.bb} (94%)

diff --git a/meta/recipes-kernel/lttng/lttng-tools/x32.patch 
b/meta/recipes-kernel/lttng/lttng-tools/x32.patch
deleted file mode 100644
index 42cebf94ac..00
--- a/meta/recipes-kernel/lttng/lttng-tools/x32.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-Fix build for x32
-
-Signed-off-by: Christopher Larson 
-
-Fix build error of src/common/utils.c for x32.
-
-Upstream-Status: Submitted [https://github.com/lttng/lttng-tools/pull/150]
-
-Signed-off-by: Kai Kang 
-
-diff --git a/src/bin/lttng/utils.c b/src/bin/lttng/utils.c
-index 0e96ef0c..5c79c8c7 100644
 a/src/bin/lttng/utils.c
-+++ b/src/bin/lttng/utils.c
-@@ -158,7 +158,7 @@ unsigned int fls_u32(uint32_t x)
- #define HAS_FLS_U32
- #endif
- 
--#if defined(__x86_64)
-+#if defined(__x86_64) && !defined(__ILP32__)
- static inline
- unsigned int fls_u64(uint64_t x)
- {
-diff --git a/src/common/utils.c b/src/common/utils.c
-index 08139e5e..3c389981 100644
 a/src/common/utils.c
-+++ b/src/common/utils.c
-@@ -1223,7 +1223,7 @@ static inline unsigned int fls_u32(uint32_t x)
- #define HAS_FLS_U32
- #endif
- 
--#if defined(__x86_64)
-+#if defined(__x86_64) && !defined(__ILP32__)
- static inline
- unsigned int fls_u64(uint64_t x)
- {
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.12.0.bb
similarity index 94%
rename from meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.12.0.bb
index 36a19ec18d..3aaf4490d6 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.12.0.bb
@@ -5,9 +5,9 @@ to extract program execution details from the Linux operating 
system \
 and interpret them."
 
 LICENSE = "GPLv2 & LGPLv2.1"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
-file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=40ef17463fbd6f377db3c47b1cbaded8 \
+
file://LICENSES/GPL-2.0;md5=e68f69a54b44ba526ad7cb963e18fbce \
+
file://LICENSES/LGPL-2.1;md5=9920968d0f2ff585ce61fae30344dd95"
 
 DEPENDS = "liburcu popt libxml2 util-linux"
 RDEPENDS_${PN} = "libgcc"
@@ -29,15 +29,14 @@ PACKAGECONFIG[manpages] = "--enable-man-pages, 
--disable-man-pages, asciidoc-nat
 PACKAGECONFIG_remove_arc = "lttng-ust"
 
 SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
-   file://x32.patch \
file://0001-tests-do-not-strip-a-helper-library.patch \
file://run-ptest \
file://lttng-sessiond.service \
file://0001-tests-regression-disable-the-tools-live-tests.patch \
"
 
-SRC_URI[md5sum] = "68ed78f7fa4235477ea577e48b3cd245"
-SRC_URI[sha256sum] = 
"936477305b25f65c5dd22db9161287d30a309ce868b6180857b1fd1fb5e6a56b"
+SRC_URI[md5sum] = "4592201ea981f0722438345fb1f009d2"
+SRC_URI[sha256sum] = 
"405661d27617dc79a42712174a051a45c7ca12d167576c0d93f2de708ed29445"
 
 inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138328): 
https://lists.openembedded.org/g/openembedded-core/message/138328
Mute This Topic: https://lists.openembedded.org/mt/74225667/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 4/4] lttng-modules: Fix "LTTng: vmalloc_sync_all symbol lookup failed" warnings

2020-05-15 Thread Ovidiu Panait
Fix the following warnings introduced after backporting linux kernel commit [1]
to stable branches:
# lttng create session
...
[  483.242037] LTTng: vmalloc_sync_all symbol lookup failed.
[  483.257056] Page fault handler and NMI tracing might trigger faults.
...

These patches should be dropped when a new stable 12.0 release is available.

[1] 
https://github.com/torvalds/linux/commit/763802b53a427ed3cbd419dbba255c414fdd9e7c

Signed-off-by: Ovidiu Panait 
---
 ...l-5.7-use-vmalloc_sync_mappings-on-k.patch | 853 ++
 ...per-rename-to-wrapper_vmalloc_sync_m.patch |  32 +
 ..._sync_mappings-on-kernel-5.6-as-well.patch |  88 ++
 ...loc_sync_mappings-for-stable-kernels.patch |  67 ++
 .../lttng/lttng-modules_2.12.0.bb |   4 +
 5 files changed, 1044 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Update-for-kernel-5.7-use-vmalloc_sync_mappings-on-k.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-Fix-missing-wrapper-rename-to-wrapper_vmalloc_sync_m.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0003-Fix-Use-vmalloc_sync_mappings-on-kernel-5.6-as-well.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0004-Update-Use-vmalloc_sync_mappings-for-stable-kernels.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-Update-for-kernel-5.7-use-vmalloc_sync_mappings-on-k.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Update-for-kernel-5.7-use-vmalloc_sync_mappings-on-k.patch
new file mode 100644
index 00..58f4d29193
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Update-for-kernel-5.7-use-vmalloc_sync_mappings-on-k.patch
@@ -0,0 +1,853 @@
+From a2cc0e06330e55eefe668f7d6370de6d3177a907 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers 
+Date: Tue, 5 May 2020 13:38:31 -0400
+Subject: [PATCH] Update for kernel 5.7: use vmalloc_sync_mappings on kernels
+ >= 5.7
+
+Upstream-Status: Backport 
[https://github.com/lttng/lttng-modules/commit/da0fcb1497ff2437407883647a8a0bba12bd0f91]
+
+Signed-off-by: Mathieu Desnoyers 
+Signed-off-by: Ovidiu Panait 
+---
+ lib/ringbuffer/ring_buffer_backend.c |  4 +--
+ lttng-abi.c  |  4 +--
+ lttng-context-callstack.c|  2 +-
+ lttng-context-cgroup-ns.c|  2 +-
+ lttng-context-cpu-id.c   |  2 +-
+ lttng-context-egid.c |  2 +-
+ lttng-context-euid.c |  2 +-
+ lttng-context-gid.c  |  2 +-
+ lttng-context-hostname.c |  2 +-
+ lttng-context-interruptible.c|  2 +-
+ lttng-context-ipc-ns.c   |  2 +-
+ lttng-context-migratable.c   |  2 +-
+ lttng-context-mnt-ns.c   |  2 +-
+ lttng-context-need-reschedule.c  |  2 +-
+ lttng-context-net-ns.c   |  2 +-
+ lttng-context-nice.c |  2 +-
+ lttng-context-perf-counters.c|  2 +-
+ lttng-context-pid-ns.c   |  2 +-
+ lttng-context-pid.c  |  2 +-
+ lttng-context-ppid.c |  2 +-
+ lttng-context-preemptible.c  |  2 +-
+ lttng-context-prio.c |  2 +-
+ lttng-context-procname.c |  2 +-
+ lttng-context-sgid.c |  2 +-
+ lttng-context-suid.c |  2 +-
+ lttng-context-tid.c  |  2 +-
+ lttng-context-uid.c  |  2 +-
+ lttng-context-user-ns.c  |  2 +-
+ lttng-context-uts-ns.c   |  2 +-
+ lttng-context-vegid.c|  2 +-
+ lttng-context-veuid.c|  2 +-
+ lttng-context-vgid.c |  2 +-
+ lttng-context-vpid.c |  2 +-
+ lttng-context-vppid.c|  2 +-
+ lttng-context-vsgid.c|  2 +-
+ lttng-context-vsuid.c|  2 +-
+ lttng-context-vtid.c |  2 +-
+ lttng-context-vuid.c |  2 +-
+ lttng-context.c  |  2 +-
+ lttng-events.c   | 10 +++---
+ lttng-ring-buffer-client.h   |  4 +--
+ lttng-ring-buffer-metadata-client.h  |  4 +--
+ lttng-syscalls.c |  2 +-
+ probes/lttng-kprobes.c   |  2 +-
+ probes/lttng-kretprobes.c|  2 +-
+ probes/lttng-tracepoint-event-impl.h |  4 +--
+ probes/lttng-uprobes.c   |  2 +-
+ probes/lttng.c   |  2 +-
+ tests/probes/lttng-test.c|  2 +-
+ wrapper/vmalloc.h| 49 ++--
+ 50 files changed, 104 insertions(+), 61 deletions(-)
+
+diff --git a/lib/ringbuffer/ring_buffer_backend.c 
b/lib/ringbuffer/ring_buffer_backend.c
+index d4bec25..d232b7f 100644
+--- a/lib/ringbuffer/ring_buffer_backend.c
 b/lib/ringbuffer/ring_buffer_backend.c
+@@ -17,7 +17,7 @@
+ #include 
+ 
+ #include 
+-#include   /* for wrapper_vmalloc_sync_all() */
++#include   /* for wrapper_vmalloc_sync_mappings() */
+ #include 
+ #include 
+ #include 
+@@ -156,7 +156,7 @@ int 

[OE-core] [PATCH 1/4] lttng-modules: upgrade to 2.12.0

2020-05-15 Thread Ovidiu Panait
Upgrade lttng-modules 2.11.2 -> 2.12.0.

Signed-off-by: Ovidiu Panait 
---
 .../{lttng-modules_2.11.2.bb => lttng-modules_2.12.0.bb}  | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-kernel/lttng/{lttng-modules_2.11.2.bb => 
lttng-modules_2.12.0.bb} (88%)

diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.12.0.bb
similarity index 88%
rename from meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb
rename to meta/recipes-kernel/lttng/lttng-modules_2.12.0.bb
index 6fff096a37..f706f89621 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.12.0.bb
@@ -13,8 +13,8 @@ SRC_URI = 
"https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
"
 
-SRC_URI[md5sum] = "2e3bc8cfb264fa13f374618b46f170e7"
-SRC_URI[sha256sum] = 
"8a42240813b8fd1d001835cd6f5ec687f7d7f3b26070d4e21604c35a51a6441d"
+SRC_URI[md5sum] = "be252df5013ea03894921d0b493c7b6c"
+SRC_URI[sha256sum] = 
"efeb2ae60e96dbe9a9b342d3a80dfc7642f06a8c09686089d491ad696bb98f4d"
 
 export INSTALL_MOD_DIR="kernel/lttng-modules"
 
@@ -33,11 +33,11 @@ python do_package_prepend() {
 BBCLASSEXTEND = "devupstream:target"
 LIC_FILES_CHKSUM_class-devupstream = 
"file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
 DEFAULT_PREFERENCE_class-devupstream = "-1"
-SRC_URI_class-devupstream = 
"git://git.lttng.org/lttng-modules;branch=stable-2.11 \
+SRC_URI_class-devupstream = 
"git://git.lttng.org/lttng-modules;branch=stable-2.12 \
file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
"
 SRCREV_class-devupstream = "17c413953603f063f2a9d6c3788bec914ce6f955"
-PV_class-devupstream = "2.11.2+git${SRCPV}"
+PV_class-devupstream = "2.12.0+git${SRCPV}"
 S_class-devupstream = "${WORKDIR}/git"
 SRCREV_FORMAT ?= "lttng_git"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138326): 
https://lists.openembedded.org/g/openembedded-core/message/138326
Mute This Topic: https://lists.openembedded.org/mt/74225657/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/4] lttng-ust: upgrade to 2.12.0

2020-05-15 Thread Ovidiu Panait
Upgrade lttng-ust 2.11.1 -> 2.12.0.

Signed-off-by: Ovidiu Panait 
---
 .../lttng/{lttng-ust_2.11.1.bb => lttng-ust_2.12.0.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-kernel/lttng/{lttng-ust_2.11.1.bb => lttng-ust_2.12.0.bb} 
(93%)

diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.11.1.bb 
b/meta/recipes-kernel/lttng/lttng-ust_2.12.0.bb
similarity index 93%
rename from meta/recipes-kernel/lttng/lttng-ust_2.11.1.bb
rename to meta/recipes-kernel/lttng/lttng-ust_2.12.0.bb
index 3bd0dfad61..ad544d1b4a 100644
--- a/meta/recipes-kernel/lttng/lttng-ust_2.11.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-ust_2.12.0.bb
@@ -31,8 +31,8 @@ SRC_URI = 
"https://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.bz2 \

file://0001-python-lttngust-Makefile.am-Add-install-lib-to-setup.patch \
"
 
-SRC_URI[md5sum] = "7de04a8ff1f0a4effa09a42620ec4081"
-SRC_URI[sha256sum] = 
"7fbab963d60741ffd4d8dd0a246f6cf168cdfe3b2385798bd90550f5f0bba869"
+SRC_URI[md5sum] = "3bf4a04c305271d13cf6596c4e7b9b3c"
+SRC_URI[sha256sum] = 
"1983edb525f3f27e3494088d8d5389b4c71af66bbfe63c6f1df2ad95aa44a528"
 
 CVE_PRODUCT = "ust"
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138327): 
https://lists.openembedded.org/g/openembedded-core/message/138327
Mute This Topic: https://lists.openembedded.org/mt/74225658/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/1] archiver.bbclass: Add ENABLE_COPYLEFT_FILTER to enable/disable copyleft_filter.bbclass

2020-05-15 Thread Robert Yang



On 5/15/20 6:32 PM, Paul Barker wrote:

On Fri, 15 May 2020 at 11:22, Robert Yang  wrote:



On 5/15/20 6:16 PM, Paul Barker wrote:

On Fri, 15 May 2020 at 10:57, Robert Yang  wrote:


Set it to 0 can make it archive all the used sources during the build, nothing
will be filtered out, this is useful when we want to archive all the sources.

This equals to:
COPYLEFT_LICENSE_INCLUDE = "*"
COPYLEFT_LICENSE_EXCLUDE = ""

But there are a lot of settings in copyleft_filter.bbclass, so it may not work
when its default settings are changed, add the var ENABLE_COPYLEFT_FILTER will
make it more reliable.


Why would copyleft_filter.bbclass not work when the settings are
changed? They're intended to be configurable.

I've been using `COPYLEFT_LICENSE_INCLUDE = "*"` in several projects
for years now. I'm not sure that we need another overlapping variable
which could confuse users further.


As you know, there other settings in copyleft_filter.bbclass may affect
the result, such as:

COPYLEFT_RECIPE_TYPES
COPYLEFT_PN_INCLUDE
COPYLEFT_PN_EXCLUDE

These settings maybe changed, and it's not easy to detect the changes,
the ENABLE_COPYLEFT_FILTER can make it more reliable.


I still don't think I understand sorry. Why can't changes be detected?
What's unreliable in the existing code? Are there specific failure
cases we can give examples of?


If one of the above variables' value is changed in a conf file, the archiver
will still work, but the results will be changed, it's not hard for advanced
users to detect that, but not easy for newbies.



I think there's a good argument for renaming copyleft_filter.bbclass
and all the variables since the names are confusing when you want the
archiver to include non-copyleft packages. But that would cause churn
and break lots of people's configs so I've never proposed it. Not sure
we need a master variable to enable/disable the whole class though.


I think that the problem is archiver's results depend on copyleft_filter
a lot, but they should be two separated functions, so I proposed a
new var to control it. But keep the current status is also OK since it
works.

// Robert



Thanks,
Paul

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138325): 
https://lists.openembedded.org/g/openembedded-core/message/138325
Mute This Topic: https://lists.openembedded.org/mt/74224037/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/1] archiver.bbclass: Add ENABLE_COPYLEFT_FILTER to enable/disable copyleft_filter.bbclass

2020-05-15 Thread Paul Barker
On Fri, 15 May 2020 at 11:22, Robert Yang  wrote:
>
>
> On 5/15/20 6:16 PM, Paul Barker wrote:
> > On Fri, 15 May 2020 at 10:57, Robert Yang  wrote:
> >>
> >> Set it to 0 can make it archive all the used sources during the build, 
> >> nothing
> >> will be filtered out, this is useful when we want to archive all the 
> >> sources.
> >>
> >> This equals to:
> >> COPYLEFT_LICENSE_INCLUDE = "*"
> >> COPYLEFT_LICENSE_EXCLUDE = ""
> >>
> >> But there are a lot of settings in copyleft_filter.bbclass, so it may not 
> >> work
> >> when its default settings are changed, add the var ENABLE_COPYLEFT_FILTER 
> >> will
> >> make it more reliable.
> >
> > Why would copyleft_filter.bbclass not work when the settings are
> > changed? They're intended to be configurable.
> >
> > I've been using `COPYLEFT_LICENSE_INCLUDE = "*"` in several projects
> > for years now. I'm not sure that we need another overlapping variable
> > which could confuse users further.
>
> As you know, there other settings in copyleft_filter.bbclass may affect
> the result, such as:
>
> COPYLEFT_RECIPE_TYPES
> COPYLEFT_PN_INCLUDE
> COPYLEFT_PN_EXCLUDE
>
> These settings maybe changed, and it's not easy to detect the changes,
> the ENABLE_COPYLEFT_FILTER can make it more reliable.

I still don't think I understand sorry. Why can't changes be detected?
What's unreliable in the existing code? Are there specific failure
cases we can give examples of?

I think there's a good argument for renaming copyleft_filter.bbclass
and all the variables since the names are confusing when you want the
archiver to include non-copyleft packages. But that would cause churn
and break lots of people's configs so I've never proposed it. Not sure
we need a master variable to enable/disable the whole class though.

Thanks,
Paul
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138324): 
https://lists.openembedded.org/g/openembedded-core/message/138324
Mute This Topic: https://lists.openembedded.org/mt/74224037/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/1] archiver.bbclass: Add ENABLE_COPYLEFT_FILTER to enable/disable copyleft_filter.bbclass

2020-05-15 Thread Robert Yang


On 5/15/20 6:16 PM, Paul Barker wrote:

On Fri, 15 May 2020 at 10:57, Robert Yang  wrote:


Set it to 0 can make it archive all the used sources during the build, nothing
will be filtered out, this is useful when we want to archive all the sources.

This equals to:
COPYLEFT_LICENSE_INCLUDE = "*"
COPYLEFT_LICENSE_EXCLUDE = ""

But there are a lot of settings in copyleft_filter.bbclass, so it may not work
when its default settings are changed, add the var ENABLE_COPYLEFT_FILTER will
make it more reliable.


Why would copyleft_filter.bbclass not work when the settings are
changed? They're intended to be configurable.

I've been using `COPYLEFT_LICENSE_INCLUDE = "*"` in several projects
for years now. I'm not sure that we need another overlapping variable
which could confuse users further.


As you know, there other settings in copyleft_filter.bbclass may affect
the result, such as:

COPYLEFT_RECIPE_TYPES
COPYLEFT_PN_INCLUDE
COPYLEFT_PN_EXCLUDE

These settings maybe changed, and it's not easy to detect the changes,
the ENABLE_COPYLEFT_FILTER can make it more reliable.

// Robert



Thanks,
Paul

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138323): 
https://lists.openembedded.org/g/openembedded-core/message/138323
Mute This Topic: https://lists.openembedded.org/mt/74224037/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/1] archiver.bbclass: Add ENABLE_COPYLEFT_FILTER to enable/disable copyleft_filter.bbclass

2020-05-15 Thread Paul Barker
On Fri, 15 May 2020 at 10:57, Robert Yang  wrote:
>
> Set it to 0 can make it archive all the used sources during the build, nothing
> will be filtered out, this is useful when we want to archive all the sources.
>
> This equals to:
> COPYLEFT_LICENSE_INCLUDE = "*"
> COPYLEFT_LICENSE_EXCLUDE = ""
>
> But there are a lot of settings in copyleft_filter.bbclass, so it may not work
> when its default settings are changed, add the var ENABLE_COPYLEFT_FILTER will
> make it more reliable.

Why would copyleft_filter.bbclass not work when the settings are
changed? They're intended to be configurable.

I've been using `COPYLEFT_LICENSE_INCLUDE = "*"` in several projects
for years now. I'm not sure that we need another overlapping variable
which could confuse users further.

Thanks,
Paul
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138322): 
https://lists.openembedded.org/g/openembedded-core/message/138322
Mute This Topic: https://lists.openembedded.org/mt/74224037/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/1] archiver.bbclass: Fix for do_populate_sdk

2020-05-15 Thread Robert Yang



On 5/15/20 6:00 PM, Paul Barker wrote:

Robert,

I recommend we use the following patch instead as it's simpler: 
https://lists.openembedded.org/g/openembedded-core/message/136168


Yes, that looks better, then please ignore my patch.

// Robert



Thanks,
Paul

On Fri, 15 May 2020 at 10:31, Robert Yang > wrote:


Fixed:
$ bitbake core-image-minimal -cpopulate_sdk

Check tmp-glibc/deploy/sources, no source is archived, this patch fixes the
problem.

Signed-off-by: Robert Yang mailto:liezhi.y...@windriver.com>>
---
  meta/classes/archiver.bbclass | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 48b4913a9f..49f96bdce6 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -592,4 +592,8 @@ python () {
      # gets added or removed (by adding or removing archiver.bbclass).
      if bb.data.inherits_class('kernel-yocto', d):
          bb.build.addtask('do_kernel_configme', 'do_configure',
'do_unpack_and_patch', d)
+
+    # For populate_sdk
+    if bb.data.inherits_class('image', d):
+        d.appendVarFlag('do_populate_sdk', 'recrdeptask', '
do_deploy_archives')
  }
-- 
2.21.0




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138321): 
https://lists.openembedded.org/g/openembedded-core/message/138321
Mute This Topic: https://lists.openembedded.org/mt/74223857/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/1] archiver.bbclass: Fix for do_populate_sdk

2020-05-15 Thread Paul Barker
Robert,

I recommend we use the following patch instead as it's simpler:
https://lists.openembedded.org/g/openembedded-core/message/136168

Thanks,
Paul

On Fri, 15 May 2020 at 10:31, Robert Yang  wrote:

> Fixed:
> $ bitbake core-image-minimal -cpopulate_sdk
>
> Check tmp-glibc/deploy/sources, no source is archived, this patch fixes the
> problem.
>
> Signed-off-by: Robert Yang 
> ---
>  meta/classes/archiver.bbclass | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
> index 48b4913a9f..49f96bdce6 100644
> --- a/meta/classes/archiver.bbclass
> +++ b/meta/classes/archiver.bbclass
> @@ -592,4 +592,8 @@ python () {
>  # gets added or removed (by adding or removing archiver.bbclass).
>  if bb.data.inherits_class('kernel-yocto', d):
>  bb.build.addtask('do_kernel_configme', 'do_configure',
> 'do_unpack_and_patch', d)
> +
> +# For populate_sdk
> +if bb.data.inherits_class('image', d):
> +d.appendVarFlag('do_populate_sdk', 'recrdeptask', '
> do_deploy_archives')
>  }
> --
> 2.21.0
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138320): 
https://lists.openembedded.org/g/openembedded-core/message/138320
Mute This Topic: https://lists.openembedded.org/mt/74223857/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/1] archiver.bbclass: Add ENABLE_COPYLEFT_FILTER to enable/disable copyleft_filter.bbclass

2020-05-15 Thread Robert Yang
Set it to 0 can make it archive all the used sources during the build, nothing
will be filtered out, this is useful when we want to archive all the sources.

This equals to:
COPYLEFT_LICENSE_INCLUDE = "*"
COPYLEFT_LICENSE_EXCLUDE = ""

But there are a lot of settings in copyleft_filter.bbclass, so it may not work
when its default settings are changed, add the var ENABLE_COPYLEFT_FILTER will
make it more reliable.

The default value is 1, has no impact by default.

Signed-off-by: Robert Yang 
---
 meta/classes/archiver.bbclass | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 48b4913a9f..f4e3478cd0 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -44,6 +44,9 @@
 COPYLEFT_RECIPE_TYPES ?= 'target native nativesdk cross crosssdk 
cross-canadian'
 inherit copyleft_filter
 
+# Set this to 0 will archive all used sources in the build
+ENABLE_COPYLEFT_FILTER ?= "1"
+
 ARCHIVER_MODE[srpm] ?= "0"
 ARCHIVER_MODE[src] ?= "patched"
 ARCHIVER_MODE[diff] ?= "0"
@@ -81,13 +84,13 @@ python () {
 pn = p
 break
 
-included, reason = copyleft_should_include(d)
-if not included:
-bb.debug(1, 'archiver: %s is excluded: %s' % (pn, reason))
-return
-else:
-bb.debug(1, 'archiver: %s is included: %s' % (pn, reason))
-
+if oe.types.boolean(d.getVar('ENABLE_COPYLEFT_FILTER')):
+included, reason = copyleft_should_include(d)
+if not included:
+bb.debug(1, 'archiver: %s is excluded: %s' % (pn, reason))
+return
+else:
+bb.debug(1, 'archiver: %s is included: %s' % (pn, reason))
 
 # glibc-locale: do_fetch, do_unpack and do_patch tasks have been deleted,
 # so avoid archiving source here.
-- 
2.21.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138319): 
https://lists.openembedded.org/g/openembedded-core/message/138319
Mute This Topic: https://lists.openembedded.org/mt/74224037/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 0/1] archiver.bbclass: Add ENABLE_COPYLEFT_FILTER to enable/disable copyleft_filter.bbclass

2020-05-15 Thread Robert Yang
The following changes since commit ce6c50ea68c34e02b487d54fdd9288e04833cdef:

  wayland: fix condition for strndup detection (2020-05-14 14:13:50 +0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/archiver2
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/archiver2

Robert Yang (1):
  archiver.bbclass: Add ENABLE_COPYLEFT_FILTER to enable/disable
copyleft_filter.bbclass

 meta/classes/archiver.bbclass | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

-- 
2.21.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138318): 
https://lists.openembedded.org/g/openembedded-core/message/138318
Mute This Topic: https://lists.openembedded.org/mt/74224036/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/1] archiver.bbclass: Fix for do_populate_sdk

2020-05-15 Thread Robert Yang
Fixed:
$ bitbake core-image-minimal -cpopulate_sdk

Check tmp-glibc/deploy/sources, no source is archived, this patch fixes the
problem.

Signed-off-by: Robert Yang 
---
 meta/classes/archiver.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 48b4913a9f..49f96bdce6 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -592,4 +592,8 @@ python () {
 # gets added or removed (by adding or removing archiver.bbclass).
 if bb.data.inherits_class('kernel-yocto', d):
 bb.build.addtask('do_kernel_configme', 'do_configure', 
'do_unpack_and_patch', d)
+
+# For populate_sdk
+if bb.data.inherits_class('image', d):
+d.appendVarFlag('do_populate_sdk', 'recrdeptask', ' 
do_deploy_archives')
 }
-- 
2.21.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138317): 
https://lists.openembedded.org/g/openembedded-core/message/138317
Mute This Topic: https://lists.openembedded.org/mt/74223857/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 0/1] archiver.bbclass: Fix for do_populate_sdk

2020-05-15 Thread Robert Yang
The following changes since commit ce6c50ea68c34e02b487d54fdd9288e04833cdef:

  wayland: fix condition for strndup detection (2020-05-14 14:13:50 +0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/archiver
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/archiver

Robert Yang (1):
  archiver.bbclass: Fix for do_populate_sdk

 meta/classes/archiver.bbclass | 4 
 1 file changed, 4 insertions(+)

-- 
2.21.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138316): 
https://lists.openembedded.org/g/openembedded-core/message/138316
Mute This Topic: https://lists.openembedded.org/mt/74223856/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] u-boot: support merging .cfg files for UBOOT_CONFIG

2020-05-15 Thread Ming Liu
> I was just thinking about something like this the other day but I
wonder if we want to apply the fragments to each config. It might be nice
if there was a way to filter out which config fragments got applied to
which u-boot configs?

Thanks for the input, yes, that would be even nicer for sure, but after
some thinking, I could not figure out a way to implement that with the
current .scc design without a complete refactoring, do you have some ideas?

In our use cases, we use .scc files as some 'feature' fragments applied to
machine configs, usually we would like them to apply to all the configs, if
there are some machine specific ones, they will be in the config file in
uboot source rather than being applied by .scc.

//Ming Liu

Joshua Watt  於 2020年5月14日 週四 下午7:03寫道:

>
> On 5/14/20 9:13 AM, Ming Liu wrote:
>
> Hi, maintainers:
>
> Ping! May I get some comments about this patch? It's been pending for
> weeks.
>
>
> I was just thinking about something like this the other day but I
> wonder if we want to apply the fragments to each config. It might be nice
> if there was a way to filter out which config fragments got applied to
> which u-boot configs?
>
>
>
> //Ming Liu
>
>  於 2020年4月6日 週一 下午9:21寫道:
>
>> From: Ming Liu 
>>
>> U-boot recipe supports .cfg files in SRC_URI, but they would be merged
>> to .config during do_configure only when UBOOT_MACHINE is set, we
>> should also support merging .cfg files for UBOOT_CONFIG.
>>
>> Signed-off-by: Ming Liu 
>> ---
>>  meta/recipes-bsp/u-boot/u-boot.inc | 17 +++--
>>  1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
>> b/meta/recipes-bsp/u-boot/u-boot.inc
>> index 188e5295cf..9126fafe0b 100644
>> --- a/meta/recipes-bsp/u-boot/u-boot.inc
>> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
>> @@ -77,7 +77,21 @@ def find_cfgs(d):
>>  return sources_list
>>
>>  do_configure () {
>> -if [ -z "${UBOOT_CONFIG}" ]; then
>> +if [ -n "${UBOOT_CONFIG}" ]; then
>> +unset i j
>> +for config in ${UBOOT_MACHINE}; do
>> +i=$(expr $i + 1);
>> +for type in ${UBOOT_CONFIG}; do
>> +j=$(expr $j + 1);
>> +if [ $j -eq $i ]; then
>> +KCONFIG_CONFIG=${S}/configs/${config%_*}_defconfig
>> merge_config.sh -m ${S}/configs/${config%_*}_defconfig ${@"
>> ".join(find_cfgs(d))}
>> +oe_runmake -C ${S} O=${B}/${config} ${config}
>> +fi
>> +done
>> +unset  j
>> +done
>> +unset  i
>> +else
>>  if [ -n "${UBOOT_MACHINE}" ]; then
>>  oe_runmake -C ${S} O=${B} ${UBOOT_MACHINE}
>>  else
>> @@ -114,7 +128,6 @@ do_compile () {
>>  j=$(expr $j + 1);
>>  if [ $j -eq $i ]
>>  then
>> -oe_runmake -C ${S} O=${B}/${config} ${config}
>>  oe_runmake -C ${S} O=${B}/${config}
>> ${UBOOT_MAKE_TARGET}
>>  for binary in ${UBOOT_BINARIES}; do
>>  k=$(expr $k + 1);
>> --
>> 2.26.0
>>
>>
> 
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138315): 
https://lists.openembedded.org/g/openembedded-core/message/138315
Mute This Topic: https://lists.openembedded.org/mt/72819498/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] bitbake.conf: support persistent /var/tmp

2020-05-15 Thread Changqing Li
From: Changqing Li 

Steps:
1. build out rootfs core-image-minimal-qemux86-64-20200514073622.rootfs.tar.bz2
2. docker import
./core-image-minimal-qemux86-64-20200514073622.rootfs.tar.bz2 poky:1.0
3. docker run -it --rm poky:1.0 /bin/sh
4. cd /var; ls -al
   there is link: tmp -> volatile/tmp
5. cd ./volatile; ls -al
   empty dir, this make link in step 4 is dad link.

in step3, since we don't launch container with init system,
volatile/tmp is not created, and the dad link may cause
error. support persistent /var/tmp can resolve this problem

And we can also resolve the problem by run with init system:
docker run -it --rm poky:1.0 /sbin/init
but maybe provide a selection to use persistent storeage is better.

To support persistent /var/tmp, rename VOLATILE_LOG_DIR
to VOLATILE_DIR

Don't use VOLATILE_LOG_DIR/VOLATILE_TMP_DIR
to control it separately since it will make things complicated,
we need to make kinds of fs-perms*.txt for kinds of combination
of the two variables.

Signed-off-by: Changqing Li 
---
 meta/conf/bitbake.conf | 10 ++
 ...erms-persistent-log.txt => fs-perms-persistent.txt} |  2 --
 meta/recipes-core/base-files/base-files_3.0.14.bb  |  7 ---
 .../recipes-core/initscripts/initscripts-1.0/volatiles |  3 ---
 meta/recipes-core/initscripts/initscripts_1.0.bb   |  8 +++-
 meta/recipes-core/systemd/systemd_245.5.bb |  4 +++-
 meta/recipes-core/udev/eudev_3.2.9.bb  |  3 +++
 7 files changed, 23 insertions(+), 14 deletions(-)
 rename meta/files/{fs-perms-persistent-log.txt => fs-perms-persistent.txt} 
(95%)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index bdade79abe..8fd688c793 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -86,9 +86,11 @@ USRBINPATH_class-nativesdk = "/usr/bin"
 # Root home directory
 ROOT_HOME ??= "/home/root"
 
-# If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links to 
/var/volatile/log.
-# If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is on 
persistent storage.
-VOLATILE_LOG_DIR ?= "yes"
+# If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links to
+# /var/volatile/log, /var/tmp links to /var/volatile/tmp
+# If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log and /var/tmp
+# is on persistent storage.
+VOLATILE_DIR ?= "yes"
 
 ##
 # Architecture-dependent build variables.
@@ -350,7 +352,7 @@ FILESEXTRAPATHS ?= "__default:"
 #  datadir, sysconfdir, servicedir, sharedstatedir, localstatedir, infodir,
 #  mandir, docdir, bindir, sbindir, libexecdir, libdir, includedir and
 #  oldincludedir
-FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt' if 
oe.types.boolean(d.getVar('VOLATILE_LOG_DIR')) else 
'files/fs-perms-persistent-log.txt'}"
+FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt' if 
oe.types.boolean(d.getVar('VOLATILE_DIR')) else 
'files/fs-perms-persistent.txt'}"
 
 ##
 # General work and output directories for the build system.
diff --git a/meta/files/fs-perms-persistent-log.txt 
b/meta/files/fs-perms-persistent.txt
similarity index 95%
rename from meta/files/fs-perms-persistent-log.txt
rename to meta/files/fs-perms-persistent.txt
index 3a7cf3ab94..9ca9571e6e 100644
--- a/meta/files/fs-perms-persistent-log.txt
+++ b/meta/files/fs-perms-persistent.txt
@@ -47,7 +47,6 @@ ${oldincludedir}  0755rootroottrue0644
rootroot
 # Links
 ${localstatedir}/run   link/run
 ${localstatedir}/lock  link/run/lock
-${localstatedir}/tmp   linkvolatile/tmp
 
 /home  0755rootrootfalse - - -
 /srv   0755rootrootfalse - - -
@@ -57,7 +56,6 @@ ${localstatedir}/local0755rootroot
false - - -
 # Special permissions from base-files
 # Set 1777
 /tmp   01777   rootrootfalse - - -
-${localstatedir}/volatile/tmp  01777   rootrootfalse - - -
 
 # Set 0700
 ${ROOT_HOME}   0700rootrootfalse - - -
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb 
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 94299431f6..0e06629bbd 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -29,7 +29,7 @@ S = "${WORKDIR}"
 INHIBIT_DEFAULT_DEPS = "1"
 
 docdir_append = "/${P}"
-dirs1777 = "/tmp ${localstatedir}/volatile/tmp"
+dirs1777 = "/tmp ${localstatedir}/${@'volatile/' if 
oe.types.boolean('${VOLATILE_DIR}') else ''}tmp"
 dirs2775 = ""
 dirs555 = "/sys /proc"
 dirs755 = "/boot /dev ${base_bindir} ${base_sbindir} ${base_libdir} \
@@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir} ${base_sbindir} 
${base_libdir} \
${localstatedir}/backups ${localstatedir}/lib \
${localstatedir}/lib/misc