[OE-core] packagegroup-base.bb override syntax

2023-12-03 Thread Vincent Prince 
Hello,

I just came back to Yocto after several years of pause, I see that
there is a new override syntax, and I'm wondering why the following
line is not changed ?

https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-base.bb?h=master-next#n125

DEPENDS_packagegroup-distro-base = "${DISTRO_EXTRA_DEPENDS}"

(and not DEPENDS:packagegroup-distro-base)

Sorry by advance if this question has trivial response

Best regards,
Vincent

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191710): 
https://lists.openembedded.org/g/openembedded-core/message/191710
Mute This Topic: https://lists.openembedded.org/mt/102949698/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][kirkstone][PATCH] glibc: Update to latest on stable 2.35 branch

2023-10-10 Thread Vincent Prince 
Fetching on the networked machine was ok.
I managed to get rid of the problem by cleaning glibc and
cross-localedef-native downloads  and sstate-cache from both machines
gitshallow_sourceware.org.git.glibc.git_561e9da-1_release.2.35.master.tar.gz
gitshallow_sourceware.org.git.glibc.git_561e9da-1_release.2.35.master.tar.gz.done
gitshallow_sourceware.org.git.glibc.git_c84018a-1_release.2.35.master.tar.gz
gitshallow_sourceware.org.git.glibc.git_c84018a-1_release.2.35.master.tar.gz.done
git2/sourceware.org.git.glibc.git
git2/sourceware.org.git.glibc.git.done

 and relaunching the build, not sure what happened here, maybe
something related to
SRCREV_FORMAT // SRCREV_glibc // SRCREV_localedef variables that does
not trigger cache/download recomputing?


Le lun. 9 oct. 2023 à 23:08, Marko, Peter  a écrit :
>
> -Original Message-
> From: Vincent Prince 
> Sent: Monday, October 9, 2023 21:09
> To: Marko, Peter (ADV D EU SK BFS1) 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][kirkstone][PATCH] glibc: Update to latest on stable 
> 2.35 branch
>
> > Hello,
> >
> > I have a small question concerning glibc source handling.
> >
> > I have a machine connected to the Internet that runs
> > bitbake -k -f --runall=fetch universe
> > and another offline machine that uses the previous fetch as a source mirror.
> > When I bitbake my image, it fails to use this with
> >
> > ERROR: cross-localedef-native-2.35-r0 do_fetch: Bitbake Fetcher Error:
> > NetworkAccess('git://sourceware.org/git/glibc.git;branch=release/2.35/master;name=glibc',
> > 'LANG=C git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c
> > core.pager=cat fetch -f --progress git://sourceware.org/git/glibc.git
> > refs/heads/*:refs/heads/* refs/tags/*:refs/tags/*')
> > It seems git archives seem corrupted?
> >
> > Do you know what could be causing this?
> > Best regards,
> > Vincent
>
> Fetch works for me and since it was merged also on autobuilder.
> What I can imagine is that your fetch on networked machine failed (e.g. due 
> to temporary network problem).
> Did you check log on the networked machine?
>
> Peter
>
> >
> > Le ven. 6 oct. 2023 à 22:10, Peter Marko via lists.openembedded.org
> >  a écrit :
> > >
> > > From: Peter Marko 
> > >
> > > Adresses CVE-2023-4911.
> > >
> > > Single commit bump:
> > > * c84018a05ae tunables: Terminate if end of input is reached 
> > > (CVE-2023-4911)
> > >
> > > Signed-off-by: Peter Marko 
> > > ---
> > >  meta/recipes-core/glibc/glibc-version.inc | 2 +-
> > >  meta/recipes-core/glibc/glibc_2.35.bb | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/meta/recipes-core/glibc/glibc-version.inc 
> > > b/meta/recipes-core/glibc/glibc-version.inc
> > > index c23a43576c..e0d47f283b 100644
> > > --- a/meta/recipes-core/glibc/glibc-version.inc
> > > +++ b/meta/recipes-core/glibc/glibc-version.inc
> > > @@ -1,6 +1,6 @@
> > >  SRCBRANCH ?= "release/2.35/master"
> > >  PV = "2.35"
> > > -SRCREV_glibc ?= "73d4ce728a59deb2fd18969e559769b3f590fac9"
> > > +SRCREV_glibc ?= "c84018a05aec80f5ee6f682db0da1130b0196aef"
> > >  SRCREV_localedef ?= "794da69788cbf9bf57b59a852f9f11307663fa87"
> > >
> > >  GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
> > > diff --git a/meta/recipes-core/glibc/glibc_2.35.bb 
> > > b/meta/recipes-core/glibc/glibc_2.35.bb
> > > index b4bad5b7ac..271520f76b 100644
> > > --- a/meta/recipes-core/glibc/glibc_2.35.bb
> > > +++ b/meta/recipes-core/glibc/glibc_2.35.bb
> > > @@ -17,7 +17,7 @@ CVE_CHECK_IGNORE += "CVE-2019-1010022 CVE-2019-1010023 
> > > CVE-2019-1010024"
> > >  CVE_CHECK_IGNORE += "CVE-2019-1010025"
> > >
> > >  # To avoid these in cve-check reports since the recipe version did not 
> > > change
> > > -CVE_CHECK_IGNORE += "CVE-2023-4813 CVE-2023-4806 CVE-2023-5156"
> > > +CVE_CHECK_IGNORE += "CVE-2023-4813 CVE-2023-4806 CVE-2023-4911 
> > > CVE-2023-5156"
> > >
> > >  DEPENDS += "gperf-native bison-native"
> > >
> > > --
> > > 2.30.2
> > >
> > >
> > > 
> > >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188879): 
https://lists.openembedded.org/g/openembedded-core/message/188879
Mute This Topic: https://lists.openembedded.org/mt/101805676/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][kirkstone][PATCH] glibc: Update to latest on stable 2.35 branch

2023-10-09 Thread Vincent Prince 
Hello,

I have a small question concerning glibc source handling.

I have a machine connected to the Internet that runs
bitbake -k -f --runall=fetch universe
and another offline machine that uses the previous fetch as a source mirror.
When I bitbake my image, it fails to use this with

ERROR: cross-localedef-native-2.35-r0 do_fetch: Bitbake Fetcher Error:
NetworkAccess('git://sourceware.org/git/glibc.git;branch=release/2.35/master;name=glibc',
'LANG=C git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c
core.pager=cat fetch -f --progress git://sourceware.org/git/glibc.git
refs/heads/*:refs/heads/* refs/tags/*:refs/tags/*')
It seems git archives seem corrupted?

Do you know what could be causing this?
Best regards,
Vincent

Le ven. 6 oct. 2023 à 22:10, Peter Marko via lists.openembedded.org
 a écrit :
>
> From: Peter Marko 
>
> Adresses CVE-2023-4911.
>
> Single commit bump:
> * c84018a05ae tunables: Terminate if end of input is reached (CVE-2023-4911)
>
> Signed-off-by: Peter Marko 
> ---
>  meta/recipes-core/glibc/glibc-version.inc | 2 +-
>  meta/recipes-core/glibc/glibc_2.35.bb | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-version.inc 
> b/meta/recipes-core/glibc/glibc-version.inc
> index c23a43576c..e0d47f283b 100644
> --- a/meta/recipes-core/glibc/glibc-version.inc
> +++ b/meta/recipes-core/glibc/glibc-version.inc
> @@ -1,6 +1,6 @@
>  SRCBRANCH ?= "release/2.35/master"
>  PV = "2.35"
> -SRCREV_glibc ?= "73d4ce728a59deb2fd18969e559769b3f590fac9"
> +SRCREV_glibc ?= "c84018a05aec80f5ee6f682db0da1130b0196aef"
>  SRCREV_localedef ?= "794da69788cbf9bf57b59a852f9f11307663fa87"
>
>  GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
> diff --git a/meta/recipes-core/glibc/glibc_2.35.bb 
> b/meta/recipes-core/glibc/glibc_2.35.bb
> index b4bad5b7ac..271520f76b 100644
> --- a/meta/recipes-core/glibc/glibc_2.35.bb
> +++ b/meta/recipes-core/glibc/glibc_2.35.bb
> @@ -17,7 +17,7 @@ CVE_CHECK_IGNORE += "CVE-2019-1010022 CVE-2019-1010023 
> CVE-2019-1010024"
>  CVE_CHECK_IGNORE += "CVE-2019-1010025"
>
>  # To avoid these in cve-check reports since the recipe version did not change
> -CVE_CHECK_IGNORE += "CVE-2023-4813 CVE-2023-4806 CVE-2023-5156"
> +CVE_CHECK_IGNORE += "CVE-2023-4813 CVE-2023-4806 CVE-2023-4911 CVE-2023-5156"
>
>  DEPENDS += "gperf-native bison-native"
>
> --
> 2.30.2
>
>
> 
>

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

[OE-core] volatile-binds: VOLATILE_LIB_DIR

2019-04-11 Thread Vincent Prince 
Hi all,

I'm wondering if it makes sense to add a VOLATILE_LIB_DIR option same way
as VOLATILE_LOG_DIR but for /var/lib folder?

I'm asking because I can't append VOLATILE_BINDS with folders inside
/var/lib as it fails on ConditionPathIsReadWrite (/var/lib is writable
after bindmounting to /var/volatile/lib) and also goes into trouble with
inner overlays.

One way to fix it in my case is to redefines entirely VOLATILE_BINDS
variable, so maybe it's not worth the effort?

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

[OE-core] [PATCH v3] Systemd: Add pattern matching support to PACKAGECONFIG

2019-03-28 Thread Vincent Prince 
libpcre2 is needed to enable grep option to journalctl.

Signed-off-by: Vincent Prince 
---

Changes in v3:
- Reformat commit message

Changes in v2:
- Fix false case option


 meta/recipes-core/systemd/systemd_241.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index a12b9ab..bfbfc81 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -151,6 +151,7 @@ PACKAGECONFIG[nss-mymachines] = 
"-Dnss-mymachines=true,-Dnss-mymachines=false"
 PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
 PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
 PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
+PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=false,libpcre2"
 PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
 PACKAGECONFIG[portabled] = "-Dportabled=true,-Dportabled=false"
 PACKAGECONFIG[qrencode] = "-Dqrencode=true,-Dqrencode=false,qrencode"
-- 
2.7.4

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

Re: [OE-core] [PATCH v2] Systemd: Add pattern matching support to PACKAGECONFIG

2019-03-27 Thread Vincent Prince 
Hi Pierre-Jean,

Thanks for your review, I'll rework commit log in V3 tomorrow,

Regards,
Vincent

Le mer. 27 mars 2019 à 16:57, TEXIER Pierre-Jean  a
écrit :

> Hi Vincent,
>
> Le mer. 27 mars 2019 à 16:45, Vincent Prince 
> a écrit :
>
>> libpcre2 is needed to enable grep option to journalctl.
>>
>> Changes in v2:
>> - Fix false case option
>>
>> Signed-off-by: Vincent Prince 
>> ---
>>  meta/recipes-core/systemd/systemd_241.bb | 1 +
>>  1 file changed, 1 insertion(+)
>>
>
> The changelog should be added below the "---" line in the patch,
> this allows to not get included into the actual commit log.
>
> Pierre-Jean
>
>
>> diff --git a/meta/recipes-core/systemd/systemd_241.bb
>> b/meta/recipes-core/systemd/systemd_241.bb
>> index a12b9ab..bfbfc81 100644
>> --- a/meta/recipes-core/systemd/systemd_241.bb
>> +++ b/meta/recipes-core/systemd/systemd_241.bb
>> @@ -151,6 +151,7 @@ PACKAGECONFIG[nss-mymachines] =
>> "-Dnss-mymachines=true,-Dnss-mymachines=false"
>>  PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
>>  PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
>>  PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
>> +PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=false,libpcre2"
>>  PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
>>  PACKAGECONFIG[portabled] = "-Dportabled=true,-Dportabled=false"
>>  PACKAGECONFIG[qrencode] = "-Dqrencode=true,-Dqrencode=false,qrencode"
>> --
>> 2.7.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] target-sdk-provides-dummy: add more perl modules to avoid populate_sdk failure

2019-03-27 Thread Vincent Prince 
Hi Alexander,

I added those to fix issue raised by lcov recipe, I'll check again tomorrow.

Regards,
Vincent

Le mer. 27 mars 2019 à 14:05, Alexander Kanavin  a
écrit :

> Can you specify in detail what the failure is please? It is not
> happening on the AB.
>
> Alex
>
> On Wed, 27 Mar 2019 at 13:59, Vincent Prince
>  wrote:
> >
> > Signed-off-by: Vincent Prince 
> > ---
> >  meta/recipes-core/meta/target-sdk-provides-dummy.bb | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> > index 60499f7..85472a8 100644
> > --- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> > +++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> > @@ -20,6 +20,7 @@ DUMMYPROVIDES = "\
> >  libxml-parser-perl \
> >  perl-module-bytes \
> >  perl-module-carp \
> > +perl-module-config \
> >  perl-module-constant \
> >  perl-module-data-dumper \
> >  perl-module-errno \
> > @@ -35,10 +36,12 @@ DUMMYPROVIDES = "\
> >  perl-module-getopt-long \
> >  perl-module-io-file \
> >  perl-module-overload \
> > +perl-module-overloading \
> >  perl-module-posix \
> >  perl-module-thread-queue \
> >  perl-module-threads \
> >  perl-module-warnings \
> > +perl-module-warnings-register \
> >  /bin/sh \
> >  /bin/bash \
> >  /usr/bin/env \
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] Systemd: Add pattern matching support to PACKAGECONFIG

2019-03-27 Thread Vincent Prince 
libpcre2 is needed to enable grep option to journalctl.

Changes in v2:
- Fix false case option

Signed-off-by: Vincent Prince 
---
 meta/recipes-core/systemd/systemd_241.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index a12b9ab..bfbfc81 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -151,6 +151,7 @@ PACKAGECONFIG[nss-mymachines] = 
"-Dnss-mymachines=true,-Dnss-mymachines=false"
 PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
 PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
 PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
+PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=false,libpcre2"
 PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
 PACKAGECONFIG[portabled] = "-Dportabled=true,-Dportabled=false"
 PACKAGECONFIG[qrencode] = "-Dqrencode=true,-Dqrencode=false,qrencode"
-- 
2.7.4

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

Re: [OE-core] [PATCH] Systemd: Add pattern matching support to PACKAGECONFIG

2019-03-27 Thread Vincent Prince 
Ouch :/
Thanks Alex, sending V2.

Le mer. 27 mars 2019 à 16:26, Alex Kiernan  a
écrit :

> On Wed, Mar 27, 2019 at 12:47 PM Vincent Prince
>  wrote:
> >
> > libpcre2 is needed to enable grep option to journalctl.
> >
> > Signed-off-by: Vincent Prince 
> > ---
> >  meta/recipes-core/systemd/systemd_241.bb | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-core/systemd/systemd_241.bb
> b/meta/recipes-core/systemd/systemd_241.bb
> > index a12b9ab..9e05944 100644
> > --- a/meta/recipes-core/systemd/systemd_241.bb
> > +++ b/meta/recipes-core/systemd/systemd_241.bb
> > @@ -151,6 +151,7 @@ PACKAGECONFIG[nss-mymachines] =
> "-Dnss-mymachines=true,-Dnss-mymachines=false"
> >  PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
> >  PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
> >  PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
> > +PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=true,libpcre2"
>
> You've got "pcre2=true" in both arms of the PACKAGECONFIG.
>
> >  PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
> >  PACKAGECONFIG[portabled] = "-Dportabled=true,-Dportabled=false"
> >  PACKAGECONFIG[qrencode] = "-Dqrencode=true,-Dqrencode=false,qrencode"
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Alex Kiernan
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] target-sdk-provides-dummy: add more perl modules to avoid populate_sdk failure

2019-03-27 Thread Vincent Prince 
Signed-off-by: Vincent Prince 
---
 meta/recipes-core/meta/target-sdk-provides-dummy.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb 
b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
index 60499f7..85472a8 100644
--- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
+++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
@@ -20,6 +20,7 @@ DUMMYPROVIDES = "\
 libxml-parser-perl \
 perl-module-bytes \
 perl-module-carp \
+perl-module-config \
 perl-module-constant \
 perl-module-data-dumper \
 perl-module-errno \
@@ -35,10 +36,12 @@ DUMMYPROVIDES = "\
 perl-module-getopt-long \
 perl-module-io-file \
 perl-module-overload \
+perl-module-overloading \
 perl-module-posix \
 perl-module-thread-queue \
 perl-module-threads \
 perl-module-warnings \
+perl-module-warnings-register \
 /bin/sh \
 /bin/bash \
 /usr/bin/env \
-- 
2.7.4

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

[OE-core] [PATCH] Systemd: Add pattern matching support to PACKAGECONFIG

2019-03-27 Thread Vincent Prince 
libpcre2 is needed to enable grep option to journalctl.

Signed-off-by: Vincent Prince 
---
 meta/recipes-core/systemd/systemd_241.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index a12b9ab..9e05944 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -151,6 +151,7 @@ PACKAGECONFIG[nss-mymachines] = 
"-Dnss-mymachines=true,-Dnss-mymachines=false"
 PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
 PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
 PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
+PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=true,libpcre2"
 PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
 PACKAGECONFIG[portabled] = "-Dportabled=true,-Dportabled=false"
 PACKAGECONFIG[qrencode] = "-Dqrencode=true,-Dqrencode=false,qrencode"
-- 
2.7.4

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

Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Vincent Prince 
Hi Armin,

Regarding target-sdk-provides-dummy: add more perl modules to avoid
populate_sdk failure patch, I had to complete it with following bbappend:

DUMMYPROVIDES_append = "\
perl-module-warnings-register \
perl-module-config \
perl-module-overloading \
perl-module-warnings \
perl-module-file-temp \
"

Don't know if we should rework Chen Qi patch or create a new one.
By the way, can't we add every empty perl packages in dummy automatically?

Best regards,
Vincent

Le mar. 19 mars 2019 à 03:37, Armin Kuster  a écrit :

> Responses should be made by Wed March 20th 22:00:00 UTC 2019
>
> The following changes since commit
> f5a57e939e626a5b7c6de5b51799ca602ed355ed:
>
>   mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib stable/thud-next
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
>
> Alexander Kanavin (1):
>   ca-certificates: upgrade 20180409 -> 20190110
>
> André Draszik (1):
>   systemd: RDEPENDS on util-linux-umount
>
> Changqing Li (1):
>   libsndfile1: Security fix CVE-2018-19432
>
> Chen Qi (1):
>   target-sdk-provides-dummy: add more perl modules to avoid populate_sdk
> failure
>
> Douglas Royds (1):
>   libpam: libpamc is licensed under its own BSD-style licence
>
> George McCollister (1):
>   systemd: fix CVE-2019-6454
>
> Jonathan Rajotte-Julien (3):
>   lttng-ust: update to 2.10.3
>   lttng-modules: update to 2.10.9
>   lttng-tools: update to 2.9.11
>
> Mark Hatle (10):
>   gitsm.py: Fix when a submodule is defined, but not initialized
>   gitsm.py: Add support for alternative URL formats from submodule files
>   tests/fetch.py: Add alternative gitsm test case
>   gitsm.py: Optimize code and attempt to resolve locking issue
>   gitsm.py: revise unpack
>   gitsm.py: Rework the shallow fetcher and test case
>   gitsm.py: Refactor the functions and simplify the class
>   gitsm.py: Fix relative URLs
>   gitsmy.py: Fix unpack of submodules of submodules
>   gitsm: The fetcher did not process some recursive submodules properly.
>
> Ming Liu (1):
>   rm_work: sort the value of do_build dependencies
>
> Oleksandr Kravchuk (1):
>   target-sdk-provides-dummy: add perl-module-overload
>
> Richard Purdie (3):
>   target-sdk-provides-dummy: Extend to -dev and -src packages
>   systemd: Update recent CVE patches
>   kernel: Ensure an initramfs is added if configured
>
> Robert Yang (1):
>   send-error-report: Add --no-ssl to use http protocol
>
> Ross Burton (1):
>   libpng: fix CVE-2019-7317
>
>  bitbake/lib/bb/fetch2/gitsm.py | 253
> +
>  bitbake/lib/bb/tests/fetch.py  |  70 +-
>  meta/classes/kernel.bbclass|   4 +-
>  meta/classes/rm_work.bbclass   |   3 +-
>  .../recipes-core/meta/target-sdk-provides-dummy.bb |  14 ++
>  ...-not-store-the-iovec-entry-for-process-co.patch |   6 +-
>  ...ld-set-a-limit-on-the-number-of-fields-1k.patch |  56 -
>  ...nald-set-a-limit-on-the-number-of-fields.patch} |  93 ++--
>  ...nal-fix-out-of-bounds-read-CVE-2018-16866.patch |  49 
>  .../0027-journal-fix-syslog_parse_identifier.patch |  77 ---
>  ...not-remove-multiple-spaces-after-identifi.patch |  84 ---
>  .../systemd/systemd/CVE-2019-6454.patch| 210 +
>  ...e-receive-an-invalid-dbus-message-ignore-.patch |  61 +
>  meta/recipes-core/systemd/systemd_239.bb   |  10 +-
>  meta/recipes-extended/pam/libpam_1.3.0.bb  |   4 +-
>  ...ose-sk-wmem-in-sock_exceed_buf_limit-trac.patch |  67 --
>  ...g-modules_2.10.7.bb => lttng-modules_2.10.9.bb} |   5 +-
>  ...ow-multiple-attempts-to-connect-to-relayd.patch |  17 +-
>  ...{lttng-tools_2.9.5.bb => lttng-tools_2.9.11.bb} |   4 +-
>  .../{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}   |   4 +-
>  .../libpng/libpng/CVE-2019-7317.patch  |  20 ++
>  meta/recipes-multimedia/libpng/libpng_1.6.36.bb|   3 +-
>  .../libsndfile/libsndfile1/CVE-2018-19432.patch| 115 ++
>  .../libsndfile/libsndfile1_1.0.28.bb   |   1 +
>  ...tes_20180409.bb => ca-certificates_20190110.bb} |   2 +-
>  scripts/send-error-report  |  11 +-
>  26 files changed, 758 insertions(+), 485 deletions(-)
>  delete mode 100644
> meta/recipes-core/systemd/systemd/0025-journald-set-a-limit-on-the-number-of-fields-1k.patch
>  rename
> meta/recipes-core/systemd/systemd/{0026-journal-remote-set-a-limit-on-the-number-of-fields-i.patch
> => 0025-journald-set-a-limit-on-the-number-of-fields.patch} (47%)
>  create mode 100644
> meta/recipes-core/systemd/systemd/0026-journal-fix-out-of-bounds-read-CVE-2018-16866.patch
>  delete mode 100644
> meta/recipes-core/systemd/systemd/0027-journal-fix-syslog_parse_identifier.patch
>  delete mode 100644
>

Re: [OE-core] GO runtime crashes

2019-03-04 Thread Vincent Prince 
Khem, you can find some backtraces here:
https://github.com/prometheus/node_exporter/issues/1244, don't know if this
is enough?

Le dim. 3 mars 2019 à 16:43, Khem Raj  a écrit :

> On Sun, Mar 3, 2019 at 2:45 AM Vincent Prince
>  wrote:
> >
> > Khem,
> >
> > I'm not sure if we considere this issue as closed or if we need to dig
> root-cause here?
> >
> > I don't have any Go stuff on my build machine nor build docker.
> > Also, those random crashes came with Thud version, I didn't have any in
> Sumo, but there was a lot of changes between these two versions.
> >
> > Please tell me if I can help,
>
> I think it needs some root causing, but we know the symptoms. So
> debugging to crash and some backtraces might help
>
> > Vincent
> >
> >
> > Le jeu. 28 févr. 2019 à 19:24, Khem Raj  a écrit :
> >>
> >> On Thu, Feb 28, 2019 at 10:19 AM Damien Riegel 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Thu, 28 Feb 2019 at 09:04, Vincent Prince
> >> >  wrote:
> >> > >
> >> > > Hi Khem,
> >> > >
> >> > > GO_DYNLINK_x86-64 = "" solution works as well,
> >> > >
> >> > > Best regards,
> >> > > Vincent
> >> > >
> >> > > Le jeu. 28 févr. 2019 à 14:14, Khem Raj  a
> écrit :
> >> > >>
> >> > >> On Thu, Feb 28, 2019 at 1:35 AM Vincent Prince
> >> > >>  wrote:
> >> > >> >
> >> > >> > Hi Damien,
> >> > >> >
> >> > >> > With GO_LINKSHARED = "" it work fine.
> >> > >> >
> >> > >>
> >> > >> Please set
> >> > >> GO_DYNLINK_x86-64 = "1"
> >> > >> to
> >> > >> GO_DYNLINK_x86-64 = ""
> >> > >> in goarch.bbclass
> >> >
> >> > Well, making a change in the goarch.bbclass is way more intrusive than
> >> > changing the value in a single recipe, so it would be nice to (at
> least)
> >> > give some justification about this solution.
> >> >
> >>
> >> this will make static binaries instead, so I wonder if its doing some
> >> linking from host.
> >>
> >> > >>
> >> > >> > I'm very new to Go, does it mean that there is a mixing issue in
> go modules from Yocto and from node_exporter vendor folder, so it links
> wrongly at runtime?
> >> >
> >> > As to why the GO_LINKSHARED ="" works, I cannot tell. I just noticed
> >> > that our application was linked differently on my machine (where it
> >> > worked) and in Yocto (where it didn't work), so I tweaked link flags
> >> > until I got it to work.
> >> >
> >> > Cheers,
> >> > Damien
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] GO runtime crashes

2019-03-03 Thread Vincent Prince 
Khem,

I'm not sure if we considere this issue as closed or if we need to dig
root-cause here?

I don't have any Go stuff on my build machine nor build docker.
Also, those random crashes came with Thud version, I didn't have any in
Sumo, but there was a lot of changes between these two versions.

Please tell me if I can help,
Vincent


Le jeu. 28 févr. 2019 à 19:24, Khem Raj  a écrit :

> On Thu, Feb 28, 2019 at 10:19 AM Damien Riegel 
> wrote:
> >
> > Hi,
> >
> > On Thu, 28 Feb 2019 at 09:04, Vincent Prince
> >  wrote:
> > >
> > > Hi Khem,
> > >
> > > GO_DYNLINK_x86-64 = "" solution works as well,
> > >
> > > Best regards,
> > > Vincent
> > >
> > > Le jeu. 28 févr. 2019 à 14:14, Khem Raj  a écrit :
> > >>
> > >> On Thu, Feb 28, 2019 at 1:35 AM Vincent Prince
> > >>  wrote:
> > >> >
> > >> > Hi Damien,
> > >> >
> > >> > With GO_LINKSHARED = "" it work fine.
> > >> >
> > >>
> > >> Please set
> > >> GO_DYNLINK_x86-64 = "1"
> > >> to
> > >> GO_DYNLINK_x86-64 = ""
> > >> in goarch.bbclass
> >
> > Well, making a change in the goarch.bbclass is way more intrusive than
> > changing the value in a single recipe, so it would be nice to (at least)
> > give some justification about this solution.
> >
>
> this will make static binaries instead, so I wonder if its doing some
> linking from host.
>
> > >>
> > >> > I'm very new to Go, does it mean that there is a mixing issue in go
> modules from Yocto and from node_exporter vendor folder, so it links
> wrongly at runtime?
> >
> > As to why the GO_LINKSHARED ="" works, I cannot tell. I just noticed
> > that our application was linked differently on my machine (where it
> > worked) and in Yocto (where it didn't work), so I tweaked link flags
> > until I got it to work.
> >
> > Cheers,
> > Damien
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] GO runtime crashes

2019-02-28 Thread Vincent Prince 
Hi Khem,

GO_DYNLINK_x86-64 = "" solution works as well,

Best regards,
Vincent

Le jeu. 28 févr. 2019 à 14:14, Khem Raj  a écrit :

> On Thu, Feb 28, 2019 at 1:35 AM Vincent Prince
>  wrote:
> >
> > Hi Damien,
> >
> > With GO_LINKSHARED = "" it work fine.
> >
>
> Please set
> GO_DYNLINK_x86-64 = "1"
> to
> GO_DYNLINK_x86-64 = ""
> in goarch.bbclass
>
> > I'm very new to Go, does it mean that there is a mixing issue in go
> modules from Yocto and from node_exporter vendor folder, so it links
> wrongly at runtime?
> >
> > Thanks for the quickfix,
> > Vincent
> >
> >
> >
> >
> > Le mer. 27 févr. 2019 à 23:22, Damien Riegel 
> a écrit :
> >>
> >> On Wed, 27 Feb 2019 at 12:10, Vincent Prince
> >>  wrote:
> >> >
> >> > Hello everyone,
> >> >
> >> > I'm trying to add node_exporter from Prometheus project to an Intel
> x86-64 machine.
> >> > I made the following recipe:
> >> >
> >> >
> https://github.com/nefethael/meta-random/blob/master/recipes-connectivity/prometheus/go-nodeexporter_0.18.0.bb
> >> >
> >> > node_exporter is crashing with multiple different runtime errors, so
> I raised an issue on github:
> >> > https://github.com/prometheus/node_exporter/issues/1244
> >>
> >> I've faced the same kind of issue with a custom application of ours.
> >> The fix was to add the following line to the recipe:
> >> GO_LINKSHARED = ""
> >>
> >> Let me know if that helps.
> >>
> >> Cheers,
> >> Damien
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] GO runtime crashes

2019-02-28 Thread Vincent Prince 
 Hi Damien,

With GO_LINKSHARED = "" it work fine.

I'm very new to Go, does it mean that there is a mixing issue in go modules
from Yocto and from node_exporter vendor folder, so it links wrongly at
runtime?

Thanks for the quickfix,
Vincent




Le mer. 27 févr. 2019 à 23:22, Damien Riegel  a
écrit :

> On Wed, 27 Feb 2019 at 12:10, Vincent Prince
>  wrote:
> >
> > Hello everyone,
> >
> > I'm trying to add node_exporter from Prometheus project to an Intel
> x86-64 machine.
> > I made the following recipe:
> >
> >
> https://github.com/nefethael/meta-random/blob/master/recipes-connectivity/prometheus/go-nodeexporter_0.18.0.bb
> >
> > node_exporter is crashing with multiple different runtime errors, so I
> raised an issue on github:
> > https://github.com/prometheus/node_exporter/issues/1244
>
> I've faced the same kind of issue with a custom application of ours.
> The fix was to add the following line to the recipe:
> GO_LINKSHARED = ""
>
> Let me know if that helps.
>
> Cheers,
> Damien
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] GO runtime crashes

2019-02-27 Thread Vincent Prince 
Hello everyone,

I'm trying to add node_exporter from Prometheus project to an Intel x86-64
machine.
I made the following recipe:

https://github.com/nefethael/meta-random/blob/master/recipes-connectivity/prometheus/go-nodeexporter_0.18.0.bb

node_exporter is crashing with multiple different runtime errors, so I
raised an issue on github:
https://github.com/prometheus/node_exporter/issues/1244

I just tested node_exporter binary without cross-compiling it with Yocto
and it does not crash. So now I'm stuck with it and nobody seems to
complain about golang on ML, so if there are some GO experts here to help
me on that,

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

Re: [OE-core] [PATCH 1/1] target-sdk-provides-dummy: add more perl modules to avoid populate_sdk failure

2019-02-08 Thread Vincent Prince 
Hi all,

I also added those to my target-sdk-provides-dummy.bappend to get it work:

perl-module-config \
perl-module-warnings-register \

Maybe we could add ALLOW_EMPTY in perl recipe or add every empty
perl-module* ?

Regards,
Vincent

Le jeu. 10 janv. 2019 à 03:30, Chen Qi  a écrit :

> When 'adduser' package, which is from meta-perl layer, is added to rootfs,
> we will get do_populate_sdk failure like below.
>
> Error:
>  Problem: package perl-module-cwd-5.24.4-r0.core2_64 requires
> perl-module-dynaloader, but none of the providers can be installed
>- package perl-module-file-temp-5.24.4-r0.core2_64 requires
> perl-module-cwd, but none of the providers can be installed
>- package perl-module-dynaloader-5.24.4-r0.core2_64 requires
> perl-module-config, but none of the providers can be installed
>- package adduser-3.118-r0.core2_64 requires perl-module-file-temp, but
> none of the providers can be installed
>- package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
> conflicts with perl provided by perl-5.24.4-r0.core2_64
>
> This is because adduser depends on some perl modules which are not
> listed in target-sdk-provides-dummy.
>
> So add these perl modules to avoid such failure.
>
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-core/meta/target-sdk-provides-dummy.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> index edf07c4..26716ac 100644
> --- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> +++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> @@ -23,11 +23,14 @@ DUMMYPROVIDES = "\
>  perl-module-file-glob \
>  perl-module-file-path \
>  perl-module-file-stat \
> +perl-module-file-temp \
>  perl-module-getopt-long \
>  perl-module-io-file \
> +perl-module-overload \
>  perl-module-posix \
>  perl-module-thread-queue \
>  perl-module-threads \
> +perl-module-warnings \
>  /bin/sh \
>  /bin/bash \
>  /usr/bin/env \
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [for-sumo][PATCH] libsodium: Update SRC_URI due to inaccessible problem

2018-08-27 Thread vincent . prince . fr 
From: Vincent Prince 

Signed-off-by: Vincent Prince 
---
 meta-oe/recipes-crypto/libsodium/libsodium_1.0.11.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-crypto/libsodium/libsodium_1.0.11.bb 
b/meta-oe/recipes-crypto/libsodium/libsodium_1.0.11.bb
index cbcbe96..00fa7aa 100644
--- a/meta-oe/recipes-crypto/libsodium/libsodium_1.0.11.bb
+++ b/meta-oe/recipes-crypto/libsodium/libsodium_1.0.11.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "http://libsodium.org/;
 LICENSE = "ISC"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=c9f00492f01f5610253fde01c3d2e866"
 
-SRC_URI = 
"https://download.libsodium.org/libsodium/releases/${BPN}-${PV}.tar.gz;
+SRC_URI = 
"https://download.libsodium.org/libsodium/releases/old/unsupported/${BPN}-${PV}.tar.gz;
 SRC_URI[md5sum] = "b58928d035064b2a46fb564937b83540"
 SRC_URI[sha256sum] = 
"a14549db3c49f6ae2170cbbf4664bd48ace50681045e8dbea7c8d9fb96f9c765"
 
-- 
2.7.4

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

[OE-core] [meta-oe][for-sumo][PATCH] ltrace_git: Update SRC_URI due to inaccessible problem

2018-08-27 Thread vincent . prince . fr 
From: Junil Kim 

Existing URI service was closed and fetch error occurred.
Change existing repository to another mirrored SRC URI.

Signed-off-by: Junil Kim 
Signed-off-by: Khem Raj 
---
 meta-oe/recipes-devtools/ltrace/ltrace_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-devtools/ltrace/ltrace_git.bb 
b/meta-oe/recipes-devtools/ltrace/ltrace_git.bb
index abe015d..f4033f7 100644
--- a/meta-oe/recipes-devtools/ltrace/ltrace_git.bb
+++ b/meta-oe/recipes-devtools/ltrace/ltrace_git.bb
@@ -15,7 +15,7 @@ SRCREV = "c22d359433b333937ee3d803450dc41998115685"
 
 DEPENDS = "elfutils"
 RDEPENDS_${PN} = "elfutils"
-SRC_URI = "git://anonscm.debian.org/collab-maint/ltrace.git;branch=master \
+SRC_URI = 
"git://github.com/sparkleholic/ltrace.git;branch=master;protocol=http \
file://configure-allow-to-disable-selinux-support.patch \
file://0001-replace-readdir_r-with-readdir.patch \
file://0001-Use-correct-enum-type.patch \
-- 
2.7.4

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

Re: [OE-core] [oe] [meta-ros] ros build error on poky

2018-04-06 Thread Vincent Prince 
 Your error [name 'oe_filter_out' is not defined] means you don't have
oe_filter_out function defined in poky/meta/classes/utils.bbclass

2018-04-06 11:06 GMT+02:00 Rajath C S :

> i understand that this isnt specific to ros queries but i do have posted
> the same at the ROS mailing-list and to ROS maintainers and the issue is to
> be yet resolved perfectly.
>
> Thanks
>
> Rajath C S,
> 9964182112,
> Bangalore - 560060
>
> On Fri, Apr 6, 2018 at 12:34 PM, Rajath C S 
> wrote:
>
>> 1. i'd like to know does the process being followed in this link lead us
>> to installation of ROS-kinetic / indigo or others, hope i am clear..? that
>> is want to know if the process of including and compiling meta-ros layer
>> for yocto equal to install ros on ubuntu i mean in literal sense
>>
>> http://wiki.ros.org/hydro/Installation/OpenEmbedded
>>
>> 2. Is the wxwidgets_2.9.5.bb recipe important because i am getting the
>> below error when 'bitbake roslaunch' is used
>>
>> ERROR: ExpansionError during parsing /home/jarvis/poky/meta-ros/rec
>> ipes-extended/wxwidgets/wxwidgets_2.9.5.bb  |
>> ETA:  0:02:07
>> Traceback (most recent call last):
>> bb.data_smart.ExpansionError: Failure expanding variable CXXFLAGS[:=],
>> expression was ${@oe_filter_out('-fvisibility-inlines-hidden', ' -O2
>> -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/jarvi
>> s/poky/openembedded-core/build/tmp-glibc/work/i586-oe-linux/
>> wxwidgets/2.9.5-r0=/usr/src/debug/wxwidgets/2.9.5-r0
>> -fdebug-prefix-map=/home/jarvis/poky/openembedded-core/build
>> /tmp-glibc/work/i586-oe-linux/wxwidgets/2.9.5-r0/recipe-sysroot-native=
>> -fdebug-prefix-map=/home/jarvis/poky/openembedded-core/build
>> /tmp-glibc/work/i586-oe-linux/wxwidgets/2.9.5-r0/recipe-sysroot=
>> -fvisibility-inlines-hidden', d)} which triggered exception NameError: name
>> 'oe_filter_out' is not defined
>>
>>
>> Thanks
>>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] [meta-ros] ros build error on poky

2018-04-06 Thread Vincent Prince 
Hi,

You should contact ROS mailing-list or ROS maintainers,
see
https://github.com/bmwcarit/meta-ros#important-resources
https://github.com/bmwcarit/meta-ros#maintainers

Best regards,
Vincent

2018-04-06 9:04 GMT+02:00 Rajath C S :

> 1. i'd like to know does the process being followed in this link lead us
> to installation of ROS-kinetic / indigo or others, hope i am clear..? that
> is want to know if the process of including and compiling meta-ros layer
> for yocto equal to install ros on ubuntu i mean in literal sense
>
> http://wiki.ros.org/hydro/Installation/OpenEmbedded
>
> 2. Is the wxwidgets_2.9.5.bb recipe important because i am getting the
> below error when 'bitbake roslaunch' is used
>
> ERROR: ExpansionError during parsing /home/jarvis/poky/meta-ros/
> recipes-extended/wxwidgets/wxwidgets_2.9.5.bb  |
> ETA:  0:02:07
> Traceback (most recent call last):
> bb.data_smart.ExpansionError: Failure expanding variable CXXFLAGS[:=],
> expression was ${@oe_filter_out('-fvisibility-inlines-hidden', ' -O2
> -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/
> jarvis/poky/openembedded-core/build/tmp-glibc/work/i586-oe-
> linux/wxwidgets/2.9.5-r0=/usr/src/debug/wxwidgets/2.9.5-r0
> -fdebug-prefix-map=/home/jarvis/poky/openembedded-core/
> build/tmp-glibc/work/i586-oe-linux/wxwidgets/2.9.5-r0/recipe-sysroot-native=
> -fdebug-prefix-map=/home/jarvis/poky/openembedded-core/
> build/tmp-glibc/work/i586-oe-linux/wxwidgets/2.9.5-r0/recipe-sysroot=
> -fvisibility-inlines-hidden', d)} which triggered exception NameError: name
> 'oe_filter_out' is not defined
>
>
> Thanks
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] What is the recommended approach to upgrade Openssl?

2018-03-26 Thread Vincent Prince 
Hi,

I'd say if you start looking at CVE/security issues, I think best option is
to update the whole thing as any breach should be fixed.
As you are working on NXP product, updating Yocto version should be quite
straightforward, by replacing krogoth branch to rocko.
You can watch this presentation
https://www.youtube.com/watch?v=F5R8VXnfwYw  that
indroduces a particular workflow to ease version migrations.

Best regards,
Vincent

2018-03-23 20:53 GMT+01:00 Ryan Pabis (pabisr) :

> All,
>
>
>
> I’m working on a bundled package from NXP  that’s based on Yocto Krogroth
> (so 2015 ish).  But now I need to update openssl from 1.0.2d to 1.0.2n to
> fix multiple CVE vulnerabilities.  However, this is proving to be quite
> difficult.  I’ve been able to upgrade curl, expat, python, etc. by adding
> the new component to my layer and then updating the layer.conf file.  But
> it appears openssl is different.
>
>
>
> If I try the same approach with openssl the first thing that goes wrong is
> the openssl_1.0.2n.bb file complains about the python function .filter
> not being supported as well as hostperl-runtime-native not being found.
> So, I fix those by reverting back to .contains and changing to
> perl-native-runtime.  That seems to solve the .bb problem.  However, then I
> get an rpm error.   Which I fix by upgrading to 4.14.1. However, now I’m
> stuck with an ‘ar’ error that I can’t figure out.
>
>
>
> So, my question is A) Is this the right approach or should I be updating
> the entire openembedded layer (if so are there instructions anywhere on how
> to do that?) and B).  If my approach is ok what is causing the ‘ar’ error
> since this built previously with openssl 1.0.2d?
>
>
>
> Here is snippet of the error.
>
>
>
> | gcc  -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC
> -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
> -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DL_ENDIAN-DTERMIO
> -isystem/home/pabisr/inode/build/tmp/sysroots/x86_64-linux/usr/include
> -O2 -pipe -Wall -Wa,--noexecstack -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
> -fPIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM 
> -isystem/home/pabisr/inode/build/tmp/sysroots/x86_64-linux/usr/include
> -c -o obj_xref.o obj_xref.c
>
> | ar ../../libcrypto.a o_names.o obj_dat.o obj_lib.o obj_err.o obj_xref.o
>
> | ar: invalid option -- '.'
>
> | Usage: ar [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV]
> [--plugin ] [member-name] [count] archive-file file...
>
> |ar -M [
> |  commands:
>
> |   d- delete file(s) from the archive
>
> |   m[ab]- move file(s) in the archive
>
> |   p- print file(s) found in the archive
>
> |   q[f] - quick append file(s) to the archive
>
> |   r[ab][f][u]  - replace existing or insert new file(s) into the archive
>
> |   s- act as ranlib
>
> |   t- display contents of archive
>
> |   x[o] - extract file(s) from the archive
>
> |  command specific modifiers:
>
> |   [a]  - put file(s) after [member-name]
>
> |   [b]  - put file(s) before [member-name] (same as [i])
>
> |   [D]  - use zero for timestamps and uids/gids (default)
>
> |   [U]  - use actual timestamps and uids/gids
>
> |   [N]  - use instance [count] of name
>
> |   [f]  - truncate inserted file names
>
> |   [P]  - use full path names when matching
>
> |   [o]  - preserve original dates
>
> |   [u]  - only replace files that are newer than current archive
> contents
>
> |  generic modifiers:
>
> |   [c]  - do not warn if the library had to be created
>
> |   [s]  - create an archive index (cf. ranlib)
>
> |   [S]  - do not build a symbol table
>
> |   [T]  - make a thin archive
>
> |   [v]  - be verbose
>
> |   [V]  - display the version number
>
> |   @  - read options from 
>
> |   --target=BFDNAME - specify the target object format as BFDNAME
>
> |  optional:
>
> |   --plugin  - load the specified plugin
>
> |  emulation options:
>
> |   No emulation specific options
>
> | ar: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64
> a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little
> elf64-big elf32-little elf32-big pe-x86-64 pe-bigobj-x86-64 pe-i386 plugin
> srec symbolsrec verilog tekhex binary ihex
>
> | Makefile:37: recipe for target 'lib' failed
>
> | make[2]: *** [lib] Error 1
>
> | make[2]: Leaving directory '/home/pabisr/inode/build/tmp/
> work/x86_64-linux/openssl-native/1.0.2n-r0/openssl-1.0.2n/crypto/objects'
>
> | Makefile:88: recipe for target 'subdirs' failed
>
> | make[1]: *** [subdirs] Error 1
>
> | make[1]: Leaving directory

Re: [OE-core] [oe-core] package inclusion error

2018-03-21 Thread Vincent Prince 
Hi,

With "oe-pkgdata-util list-pkgs -p opencv" command, you can check every
packages made from opencv recipe.
One of them is python3-opencv, did you add it to IMAGE_INSTALL as well as
opencv?

Best regards,
Vincent

2018-03-21 8:18 GMT+01:00 Rajath C S :

> opencv recipe is in meta-oe layer, i have included meta-oe path in
> bblayer.config file
> and i have also included open cv in IMAGE_INSTALL and have successfully
> built the target using bitbake but still when i am doing 'import cv2' on
> python terminal on yocto's poky it says 'no moudle named cv2'. what is the
> solution?
> Thanks
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [rocko][PATCH 1/8] Revert "waf.bbclass: explicitly pass bindir and libdir if supported"

2018-03-14 Thread Vincent Prince 
Hi Stefan,

If I remember correctly, you submitted this feature?

Best Regards,
Vincent

2018-03-14 16:28 GMT+01:00 Martin Jansa :

> ping, this was in rocko-next for a while and then it disappeared.
>
> On Sun, Mar 11, 2018 at 1:43 AM, Martin Jansa 
> wrote:
>
>> * this doesn't work correctly as discussed in:
>>   http://lists.openembedded.org/pipermail/openembedded-commits
>> /2018-January/218460.html
>> * some of the issues were fixed in master since then
>>   but not all, so revert it until it's completely resolved
>>
>> This reverts commit eac21f981337bfaddb2d67161a1ff049158041ce.
>>
>> Signed-off-by: Martin Jansa 
>> ---
>>  meta/classes/waf.bbclass | 17 +
>>  1 file changed, 1 insertion(+), 16 deletions(-)
>>
>> diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
>> index acbda278a2..c4698e910a 100644
>> --- a/meta/classes/waf.bbclass
>> +++ b/meta/classes/waf.bbclass
>> @@ -25,23 +25,8 @@ def get_waf_parallel_make(d):
>>
>>  return ""
>>
>> -python waf_preconfigure() {
>> -from distutils.version import StrictVersion
>> -srcsubdir = d.getVar('S')
>> -wafbin = os.path.join(srcsubdir, 'waf')
>> -status, result = oe.utils.getstatusoutput(wafbin + " --version")
>> -if status != 0:
>> -bb.warn("Unable to execute waf --version, exit code %d. Assuming
>> waf version without bindir/libdir support." % status)
>> -return
>> -version = result.split()[1]
>> -if StrictVersion(version) >= StrictVersion("1.8.7"):
>> -d.setVar("WAF_EXTRA_CONF", "--bindir=${bindir}
>> --libdir=${libdir}")
>> -}
>> -
>> -do_configure[prefuncs] += "waf_preconfigure"
>> -
>>  waf_do_configure() {
>> -   ${S}/waf configure --prefix=${prefix} ${WAF_EXTRA_CONF}
>> ${EXTRA_OECONF}
>> +   ${S}/waf configure --prefix=${prefix} ${EXTRA_OECONF}
>>  }
>>
>>  waf_do_compile()  {
>> --
>> 2.15.1
>>
>>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] kernel-fitimage.bbclass: Deploy fitImage without Initramfs

2018-03-08 Thread Vincent Prince 
Hi Vineeth,

I think it's because this class can be found in those two repos and error
log tells it should be based on first one:

http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/kernel-fitimage.bbclass

Best regards,
Vincent

2018-03-08 5:39 GMT+01:00 Vineeth Karumanchi <
vineethchowz.chowd...@xilinx.com>:

> Hi,
>
> I am getting the patch failure error saying unable to apply.
> https://patchwork.openembedded.org/series/11297/
>
>
> I did these steps:
>
> - git clone git://git.yoctoproject.org/poky  ( master is at
> 83cd2b3e775235942dd4201622dc5cc2d4328994 )
>
> - Applied this patch, it went well.
>
>
> Can you please let me know what is the mistake .
> I was sending patch on master.
>
> Thanks
> Vineeth
>
>
>
> On 03/08/2018 09:00 AM, Vineeth Chowdary Karumanchi wrote:
>
>> This patch deploys fitImage (linux.bin + dtb ).
>> The use case is to have 2 partioned sd card, with
>> FAT partition having bootloader + fitImage and
>> ext4 partion having rootfs.
>>
>> Signed-off-by: Vineeth Chowdary Karumanchi > com>
>> ---
>> v2: Proper signed off
>> ---
>>   meta/classes/kernel-fitimage.bbclass | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/meta/classes/kernel-fitimage.bbclass
>> b/meta/classes/kernel-fitimage.bbclass
>> index 50a91e1..25884d5 100644
>> --- a/meta/classes/kernel-fitimage.bbclass
>> +++ b/meta/classes/kernel-fitimage.bbclass
>> @@ -464,6 +464,10 @@ kernel_do_deploy_append() {
>> linux_bin_base_name="fitImage-
>> linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
>> linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
>> install -m 0644 linux.bin ${DEPLOYDIR}/${linux_bin_base_
>> name}.bin
>> +   fitimage_base_name="fitImage-
>> ${PV}-${PR}-${MACHINE}-${DATETIME}"
>> +   fitimage_symlink_name=fitImage-${MACHINE}
>> +   install -m 0644 arch/${ARCH}/boot/fitImage
>> ${DEPLOYDIR}/${fitimage_base_name}.bin
>> +
>> if [ -n "${INITRAMFS_IMAGE}" ]; then
>> echo "Copying fit-image-${INITRAMFS_IMAGE}.its
>> source file..."
>> @@ -478,6 +482,7 @@ kernel_do_deploy_append() {
>> cd ${DEPLOYDIR}
>> ln -sf ${its_base_name}.its ${its_symlink_name}.its
>> ln -sf ${linux_bin_base_name}.bin
>> ${linux_bin_symlink_name}.bin
>> +   ln -sf ${fitimage_base_name}.bin
>> ${fitimage_symlink_name}.bin
>> if [ -n "${INITRAMFS_IMAGE}" ]; then
>> ln -sf ${its_initramfs_base_name}.its
>> ${its_initramfs_symlink_name}.its
>>
>>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Questions about udev rule and systemd-udev，relevant to mounting block device

2018-03-02 Thread Vincent Prince 
Hi,

I'm not sure what is your use case, but you can check usbmount[1][2]
or automount-usb[3] for example on how to use udev with systemd:

Regards,
Vincent

[1]https://github.com/rbrito/usbmount
[2]
https://github.com/nefethael/meta-random/blob/master/recipes-support/usbmount/usbmount_git.bb
[3]https://github.com/six-k/automount-usb


2018-03-02 6:44 GMT+01:00 Hongzhi, Song :

> Hi all,
>
> Does anyone have suggestion for me?
>
> Thanks.
>
> Hongzhi.Song
>
> On 2018年03月01日 18:35, Hongzhi, Song wrote:
>
> Defect:
>
> The exiting method of automount of udev in *oe-core/meta/ *is using
>
> *automount.rules* which call *mount.sh* that using */bin/mount* to mount
> device.
>
> But systemd-udevd detaches *mount()* operations done within the service
>
> from the rest of the system with MountFlag=slave， this means host can
>
> not access device. (e.g. Executing *mkfs.ext4 /dev/sda1/* prompts
>
> */dev/sda1 is apparently in use by the system; will not make a filesystem
> here!*)
>
>
> Solution:
>
> Systemd upstream suggest that the best way is to use "systemd-mount"
>
> in udev rules, which will request the mount operation to be executed by
> PID 1.
>
> And I have tested it was effective.
>
>
> Uncertain：
>
> The exiting method is designed for *SysV-init *which is not
> compatible to
>
> systemd-udev, at least that's what I think. So I think that we should
> design
>
> a new rule or organizational structure to be suitable for systemd-udev and
>
> to mount deferent device. Dose anyone help do this? Or I can make some
>
> improvements on the basis of the existing with "systemd-mount".
>
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] systemd: re-enable mount propagation for udevd

2018-02-23 Thread Vincent Prince 
Hi all,

I have MountFlags=slave defined, and I use the following recipe to
automount usb stick without right issues:
https://github.com/nefethael/meta-random/blob/master/recipes-support/usbmount/usbmount_git.bb
I think we should keep this settings as it is.

What is the problematic use case?

Best regards,
Vincent

2018-02-23 2:23 GMT+01:00 Hongzhi, Song :

> If MountFlags=slave, systemd-udevd mounts all block device,  such as
>
> '/dev/sda1' '/dev/mmcblk*' , in itself unit namespace. So other namespace,
>
> such as 'root user', has no access to use block device mentioned above.
>
>
> On 2018年02月23日 08:50, Otavio Salvador wrote:
>
>> On Thu, Feb 22, 2018 at 11:15 AM, Hongzhi.Song
>>  wrote:
>>
>>> MountFlags's default value is shared in systemd-udevd.service. But
>>> upstream
>>> sets MountFlags with slave just for keeping mounts done by udev private
>>> to
>>> udevd, which causes block device mounted by udev unvisable but being
>>> busy for
>>> host. So we revert it to shared to be propagated to host.
>>>
>>> Signed-off-by: Hongzhi.Song 
>>>
>> This is what the mountflag does. This does not explain WHY you need this
>> change.
>>
>>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] How to fix file-rdes QA error for /usr/bin/python?

2017-12-14 Thread Vincent Prince 
Steffen,

I maybe wrong but foo.py should start with
#!/usr/bin/env python

instead of
#!/usr/bin/python

Best regards,
Vincent



2017-12-14 14:34 GMT+01:00 Steffen Sledz :

> With rocko some builds are rejected because of the following package QA
> error (formerly it was just a warning).
>
>  ERROR: foo-1_gitrAUTOINC+2595b80a79-r17 do_package_qa: QA Issue:
> //foo.py contained in package foo requires /usr/bin/python, but no
> providers found in RDEPENDS_for? [file-rdeps]
>
> But the recipe still contains an rdep for python in recipe foo_git.bb
>
>  RDEPENDS_{PN} += " ... python "
>
> I assume the problem is that /usr/bin/python is not provided by any
> package but is just a symlink (created via u-a?).
>
> How can/should this be fixed?
>
> --
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

2017-12-12 Thread Vincent Prince 
As waf_do_configure takes care of EXTRA_OECONF, maybe we can only fix
gstreamer1.0-plugins-imx_0.13.0.bb by adding libdir ?
It is much a bug fix than a longterm solution, but if any waf version
breaks options, it can be a nightmare to handle...

2017-12-12 16:56 GMT+01:00 Stefan Agner :

> On 2017-12-12 16:47, Otavio Salvador wrote:
> > On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner  wrote:
> >> On 2017-12-12 15:13, Burton, Ross wrote:
> >>
> >>> On 12 December 2017 at 14:03, Stefan Agner  wrote:
> >>>
>  On 2017-12-12 15:00, Burton, Ross wrote:
> 
> > On 12 December 2017 at 13:27, Stefan Agner  wrote:
> >
> >> On some build hosts distros (e.g. Fedora 26) waf tries to be
> >> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
> >> This obviously is not what we want for 32-bit targets and usually
> >> fails in the do_package phase:
> >> WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped
> in any package:
> >> /usr/lib64/libgstimxcommon.so.0
> >>
> >> Waf knows prefix, bindir and libdir as default options. Explicitly
> >> pass those three.
> >
> > Obviously not.
> >
> > ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed:
> do_configure (log file is located at /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.
> do_configure.17278)
> > ERROR: Logfile of failure stored in: /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
> > Log data follows:
> > | DEBUG: Executing shell function do_configure
> > | waf [commands] [options]
> > |
> > | Main commands (example: ./waf build -j4)
> > |   build: executes the build
> > |   clean: cleans the project
> > |   configure: configures the project
> > |   dist : makes a tarball for redistributing the sources
> > |   distcheck: checks if the project compiles (tarball from 'dist')
> > |   distclean: removes the build directory
> > |   install  : installs the targets on the system
> > |   list : lists the targets to execute
> > |   step : executes tasks in a step-by-step fashion, for
> debugging
> > |   uninstall: removes the targets installed
> > |   update   : updates the plugins from the *waflib/extras* directory
> > |
> > | waf: error: no such option: --bindir
> >
>  Hm, eglinfo seems to come with a old waf version, 1.7.8 to be
> specific.
> 
>  It seems bindir/libdir got added in 1.8 series:
>  https://github.com/waf-project/waf/blob/waf-1.8/waflib/Options.py
> 
>  Make version specific variables?
> >>>
> >>> That neatly shows where the "clever code" that was breaking libdir
> earlier is:
> >>>
> >>> https://github.com/waf-project/waf/commit/
> 823b4cd2dc03d06a81e0ab003606067da03d8745#diff-
> b44b0c8f383b2fd1b19f2ba039d30237
> >>>
> >>
> >> Yeah that seems to be it.
> >>
> >> That go added in the 1.8.6 dev cycle afaik.
> >>
> >> I am thinking about adding some kind of version autodetection
> >>
> >> WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-9]*
> >> (.*//};q')
> >>
> >> if [ $WAFMINOR -gt "7" ] ...
> >>
> >> Maybe there is a nicer way of doing this?
> >
> > What about we provide a package waf version and replace the binaries
> > prior building? So we know what version we'd be using. Kinda
> > autoreconf run in autotools class.
>
> Waf seems to be extensible using wscript. I don't know how exactly
> wscript depends on waf (version) and whether the API is considered
> stable...
>
> I'd rather prefer not taking chances...
>
> --
> Stefan
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

2017-12-12 Thread Vincent Prince 
Hi Ross,

Does it fail with V1?

Best regards,
Vincent

2017-12-12 15:00 GMT+01:00 Burton, Ross :

> On 12 December 2017 at 13:27, Stefan Agner  wrote:
>
>> On some build hosts distros (e.g. Fedora 26) waf tries to be
>> smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
>> This obviously is not what we want for 32-bit targets and usually
>> fails in the do_package phase:
>>   WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue:
>> gstreamer1.0-plugins-imx: Files/directories were installed but not shipped
>> in any package:
>> /usr/lib64/libgstimxcommon.so.0
>>
>> Waf knows prefix, bindir and libdir as default options. Explicitly
>> pass those three.
>>
>
> Obviously not.
>
> ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed: do_configure
> (log file is located at /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.
> do_configure.17278)
> ERROR: Logfile of failure stored in: /data/poky-tmp/master/build/
> work/corei7-64-poky-linux/eglinfo-x11/1.0.0-r0/temp/log.do_configure.17278
> Log data follows:
> | DEBUG: Executing shell function do_configure
> | waf [commands] [options]
> |
> | Main commands (example: ./waf build -j4)
> |   build: executes the build
> |   clean: cleans the project
> |   configure: configures the project
> |   dist : makes a tarball for redistributing the sources
> |   distcheck: checks if the project compiles (tarball from 'dist')
> |   distclean: removes the build directory
> |   install  : installs the targets on the system
> |   list : lists the targets to execute
> |   step : executes tasks in a step-by-step fashion, for debugging
> |   uninstall: removes the targets installed
> |   update   : updates the plugins from the *waflib/extras* directory
> |
> | waf: error: no such option: --bindir
>
> Ross
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] GCC 7.2.0: Fix 0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch

2017-12-05 Thread Vincent Prince 
Patch fails to apply on peep-ldrd-1.c and peep-strd-1.c.
First chunk replace ldrd by ldrd\\t then second chunk copy peep-X-1.c to 
peep-ldrd-2.c and try to replace already patched ldrd\\t

Signed-off-by: Vincent Prince <vincent.prince...@gmail.com>
---
 .../0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/meta/recipes-devtools/gcc/gcc-7.2/0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch
 
b/meta/recipes-devtools/gcc/gcc-7.2/0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch
index 0212507..1995f64 100644
--- 
a/meta/recipes-devtools/gcc/gcc-7.2/0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch
+++ 
b/meta/recipes-devtools/gcc/gcc-7.2/0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch
@@ -158,7 +158,7 @@ index eb2b86ee7b6..6822c2b1454 100644
*p = a;
return a;
  }
--/* { dg-final { scan-assembler "ldrd" } } */
+-/* { dg-final { scan-assembler "ldrd\\t" } } */
 +/* { dg-final { scan-assembler-not "ldrd\\t" } } */
 diff --git a/gcc/testsuite/gcc.target/arm/peep-strd-1.c 
b/gcc/testsuite/gcc.target/arm/peep-strd-1.c
 index bd330769599..fe1beac7229 100644
@@ -187,7 +187,7 @@ index bd330769599..bfc5ebe9eec 100644
p[2] = a;
p[3] = b;
  }
--/* { dg-final { scan-assembler "strd" } } */
+-/* { dg-final { scan-assembler "strd\\t" } } */
 +/* { dg-final { scan-assembler-not "strd\\t" } } */
 -- 
 2.15.0
-- 
2.7.4

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