Re: [OE-core] [oe] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA

[Andrea Galbusera]

On Thu, Jan 31, 2019 at 8:26 AM Trevor Woerner  wrote:
>
> We're excited to announce the inaugural "OpenEmbedded Summit" taking place
> Sunday March 10th 2019 as part of the Southern California Linux Expo
> (SCaLE) 17x at the Pasadena Convention Center.
>
> For the past few years there's been an ever-growing OpenEmbedded event as
> part of SCaLE. This year, with the missing Spring ELC, we felt it was time
> to do something more "formally" so OE enthusiasts could get together
> without having to wait until August.
>
> The initial suggestion for this summit came at last year's OEDEM in
> Edinburgh. At that time an idea was also floated to hold this year's OEDAM
> at the same time. Just to be absolutely clear: this suggestion was
> rejected; there will be no OEDAM at the OE Summit at SCaLE 17x. However,
> this summit is taking place with the full approval of the OpenEmbedded
> Board of Directors, many of whom have also been helping out with its
> organization.
>
> The schedule for the OE Summit has been posted:
> https://www.socallinuxexpo.org/scale/17x/schedule/sunday
> https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0

To whoever can double check and fix the schedule... it looks like
there's a typo at the second link, where Alistair's talk is listed
twice. From the first link "Lokesh Kumar Goel
OpenEmbedded in LG Products" should be at 11.30am instead.

>
> So if you're in the Southern California area, or are generally interested
> in hanging out with some OpenEmbedded people, please join us in Pasadena on
> March 10th!
>
> Your OE Summit organizing committee:
>   Tom King
>   Behan Webster
>   Trevor Woerner
> --
> ___
> Openembedded-devel mailing list
> openembedded-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Official sstate premirrors and builds

[Andrea Galbusera]

Hi,

On Sat, Jan 5, 2019 at 4:21 AM Jate Sujjavanich  wrote:
>
> I setup a machine on AWS and wanted to use the sstate cache mirror at 
> sstate.yoctoproject.org in my site.conf.
>
> Bitbake does not pull the artifacts from the mirror despite the uninative C 
> library. I have tried checking out several tags and then pointed to the 
> appropriate directory on sstate mirror. For example, yocto-2.2.2 and 
> http://sstate.yoctoproject.org/2.2.2.
>
> Bitbake populates several license setscene tasks, but no native packages.
>
> Does anyone have this working?

I remember I tried this some time ago and similarly had no luck with
"official" mirrors... I guess it was after sumo release on an Ubuntu
16.04 host. I remember I used default local.conf and tried both tagged
commits and release branch tips, but I always ended up with full
builds with no sstate object being fetched from the mirror.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v6] u-boot: Add mkenvimage tool

[Andrea Galbusera]

On Thu, Nov 22, 2018 at 10:47 AM Alexey Brodkin
 wrote:
>
> Hi Otavio,
>
> On Thu, 2018-11-22 at 07:30 -0200, Otavio Salvador wrote:
> > Hello Alexey,
> >
> > On Thu, Nov 22, 2018 at 6:28 AM Alexey Brodkin
> >  wrote:
> > > This utility is used for creation of images containing
> > > usable in run-time U-Boot environment.
> > >
> > > As of today this utility is added per-board like here [1]
> > > for Intel Edison board.
> > >
> > > [1]
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.yoctoproject.org_cgit_cgit.cgi_meta-2Dintel-2Dedison_tree_meta-2Dintel-2Dedison-2Dbsp_recipes-2Dbsp_u-2Dboot_u-2Dboot-2Dtools-5F2014.04.bb=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=0oSj04biS8fsfFjYHNTIfKozS-TUjseTTeyuKHHcljA=hpwGEnrX5gArYJHLxYhMZ4x6s3irTZyCMjjnFipip7k=
> > >
> > > Given there're quite some U-Boot tools that we may want to add later
> > > this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools"
> > > still for compatibility we provide "u-boot-mkimage" with help
> > > of PROVIDES as well as proposed "u-boot-mkenvimage".
> > >
> > > Signed-off-by: Alexey Brodkin 
> > > Cc: Richard Purdie 
> > > Cc: Otavio Salvador 
> > > Cc: Martin Jansa 
> > > Cc: Ross Burton 
> > > Cc: Marek Vasut 
> >
> > Acked-by: Otavio Salvador 
> >
> > I'd like to thank you to keep the pace until it was ready. I know it
> > may be challenging to contribute to new projects and OpenEmbedded is
> > no different.
> >
> > You were very welcoming to comments and change requests and I believe
> > it was a great thread of changes which lead to a good patch. I look
> > forward to the new patches you'll start submitting from now on :-)
>
> I'd like to thank you guys as well for being patient and providing
> meaningful comments for my naive and sometime silly changes.
>
> And sure there will be more patches as now we start using OE
> for quite some projects basically trying to get ARC up to speed
> in OE as good as possible and given our architecture differs a bit
> from others (as any other arch) we're not only adding features but
> more fix issues that were not seen before due to pure luck...
> like we typically have 8k MMU page a bit exotic int64_t alignment
> by 32 bits etc so there'll be more stuff from us in the foreseeable
> future :)

Looking forward to show the iterations behind this series to
contribution newbies. It's a good example of when things work well
both sides! I had this little piece of u-boot-tools flying around in
several projects, but never found the time to figure out a reasonable
approach to reconcile it cleanly with the other u-boot components. Of
course, I'm first of all showing myself that I'd have better
contributed it at first to leverage all suggestions that came out of
this discussion. Thanks Alexey for taking care of this all!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] question: Use systemd as the default initialization manager

[Andrea Galbusera]

Hi!

On Thu, May 24, 2018 at 7:06 AM, Zheng, Ruoqin
 wrote:
> Hi All：
>
> By default, the Yocto Project uses SysVinit as the initialization manager.
> However, systemd is used by many distributions and it's supported in Yocto.
>
> Why didn't use systemd as the default initialization manager?

As you mentioned, the Yocto Project does support building and
configuring systems with either of the two init frameworks. Poky,
which is the reference distribution that comes with Yocto, uses
SysVinit by default. There's nothing bad with systemd support in
Yocto. It perfectly works and many of us are successfully building
their custom distributions (or simply Poky derivatives) with systemd.
Just follow instructions at [1] to select your preferred init system.

I'm not aware of any plan to switch default init system for Poky to
systemd. This probably more for historical than technical reasons as
of today.

[1] 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#selecting-an-initialization-manager

> --
> Zheng Ruoqin
> Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
> ADDR.: No.6 Wenzhu Road, Software Avenue,
>Nanjing, 210012, China
> MAIL : zhengrq.f...@cn.fujistu.com
>
>
>
>
> --
> ___
> 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] Running BitBake multiple times without rechecking upstream AUTOREV versions

[Andrea Galbusera]

On Tue, May 15, 2018 at 5:43 PM, Andrea Galbusera <giz...@gmail.com> wrote:
>
>
> Il 14 mag 2018 10:20 AM, "Richard Purdie"
> <richard.pur...@linuxfoundation.org> ha scritto:
>
> On Fri, 2018-05-11 at 18:23 +, Chris Laplante via Openembedded-core
> wrote:
>
>> Hi all,
>>
>> I’m working on using Jenkins to host our Yocto build. One of the
>> things that would be nice is to be able to do a “bitbake our-user-
>> image”, upload the artifacts to our network file storage, and then do
>> a “bitbake our-user-image -c populate_sdk_ext”. I’d like to do these
>> separately so that developers are not waiting around for the eSDK to
>> be generated if all they care about is the kernel, for example. My
>> concern is that the second bitbake invocation could end up building
>> different stuff if someone were to check in code in between when the
>> two “bitbake”s are run. This is primarily a concern with recipes that
>> use AUTOREV (as we do for development purposes).
>>
>> Is there a way to essentially “freeze” the BitBake data store and re-
>> use it across multiple bitbake invocations?
>
> Have you tried BB_SRCREV_POLICY = "cache"?
>
>
> Out of curiosity and probably unrelated to the OP's issue with images/SDK
> SRCREVs consistency issue Could setting this variable be of any help
> even for building usable eSDKs when AUTOREV is around? There's an issue in
> bugzilla (don't have id at hand) dealing with eSDK / AUTOREV
> incompatibility...

Here is the link to the above mentioned bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11350
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Running BitBake multiple times without rechecking upstream AUTOREV versions

[Andrea Galbusera]

Il 14 mag 2018 10:20 AM, "Richard Purdie" <
richard.pur...@linuxfoundation.org> ha scritto:

On Fri, 2018-05-11 at 18:23 +, Chris Laplante via Openembedded-core
wrote:

> Hi all,
>
> I’m working on using Jenkins to host our Yocto build. One of the
> things that would be nice is to be able to do a “bitbake our-user-
> image”, upload the artifacts to our network file storage, and then do
> a “bitbake our-user-image -c populate_sdk_ext”. I’d like to do these
> separately so that developers are not waiting around for the eSDK to
> be generated if all they care about is the kernel, for example. My
> concern is that the second bitbake invocation could end up building
> different stuff if someone were to check in code in between when the
> two “bitbake”s are run. This is primarily a concern with recipes that
> use AUTOREV (as we do for development purposes).
>
> Is there a way to essentially “freeze” the BitBake data store and re-
> use it across multiple bitbake invocations?

Have you tried BB_SRCREV_POLICY = "cache"?


Out of curiosity and probably unrelated to the OP's issue with images/SDK
SRCREVs consistency issue Could setting this variable be of any help
even for building usable eSDKs when AUTOREV is around? There's an issue in
bugzilla (don't have id at hand) dealing with eSDK / AUTOREV
incompatibility...


Cheers,

Richard

-- 
___
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] systemd: backport patch to fix build when gcrypt is enabled

[Andrea Galbusera]

On Wed, May 9, 2018 at 4:46 PM, Mark Asselstine
<mark.asselst...@windriver.com> wrote:
> On Wednesday, May 9, 2018 10:36:17 AM EDT Andrea Galbusera wrote:
>> Hi Mark!
>>
>> Il mer 9 mag 2018, 15:56 Mark Asselstine <mark.asselst...@windriver.com> ha
>>
>> scritto:
>> > On Wednesday, May 9, 2018 8:16:08 AM EDT Andrea Galbusera wrote:
>> > > When gcrypt support is present in PACKAGECONFIG, build fails due to the
>> >
>> > bug
>> >
>> > > reported in [1]. Since this is already solved upstream, this commit
>> > > backports the corresponding patch.
>> > >
>> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893602
>> > >
>> > > Signed-off-by: Andrea Galbusera <giz...@gmail.com>
>> >
>> > Thanks Andrea, I can confirm this fixes a build failure we were seeing as
>> > well.
>>
>> Thanks for further testing the patch so quickly!
>
> No problem. I had a build going with the same upstream patch in place when I
> saw your email.
>
>>
>> Out of curiosity... Are you also enabling gcrypt support to workaround the
>> implict dependency resolved used to have upon gcrypt in the past?
>
> We have been enabling gcrypt since 2016 when building systemd. We found that
> there was upstream work which meant that gcrypt was necessary and not optional
> (as it appeared). I don't think we ever revisited this since that initial
> discovery.

Exactly same situation here! ;-) I asked in the hope I could hijack
updates on the same old and somewhat confusing topic. I took the time
to revisit my application layer to drop systemd features that now
built by default (namely networkd and resolved) when the gcrypt
not-so-optional issue come to mind...

>
>> It took
>> me a few hours to figure out what was specific in my configuration, since
>> this bug was obviously not exposed in configurations currently built by the
>> autobuilders!
>
> We do nightly builds of meta-overc (https://github.com/OverC/meta-overc) where
> we often catch things the autobuilds miss. You most likely don't care about
> the content of meta-overc but it might be worthwhile to keep an eye on commits
> we do there since we often stage systemd and other fixes there while they are
> pending for other oe/yocto repos.

Good to know! ;-)

>
>>
>> As a side note, I know there is a newer released version of systemd (238),
>> but upgrading such a complex recipe was not an option for me in the short.
>> I'm CC-ing the recipe's maintainer here, in case there's already an effort
>> to upgrade to 238...
>
> Makes sense, it's the "smart thing to do". Since meta-overc does lots of work
> around containers we can be sensitive to systemd uprev's but are usually quick
> to address any issues the uprev might cause.
>
> Mark
>
>>
>> > Mark
>> >
>> > > ---
>> > >
>> > >  ...rename-noreturn-into-_noreturn_-8456.patch | 203 ++
>> > >  meta/recipes-core/systemd/systemd_237.bb  |   1 +
>> > >  2 files changed, 204 insertions(+)
>> > >  create mode 100644
>> > >
>> > > meta/recipes-core/systemd/systemd/0033-basic-macros-
>> >
>> > rename-noreturn-into-_n
>> >
>> > > oreturn_-8456.patch
>> > >
>> > > diff --git
>> > > a/meta/recipes-core/systemd/systemd/0033-basic-macros-
>> >
>> > rename-noreturn-into-
>> >
>> > > _noreturn_-8456.patch
>> > > b/meta/recipes-core/systemd/systemd/0033-basic-macros-
>> >
>> > rename-noreturn-into-
>> >
>> > > _noreturn_-8456.patch new file mode 100644
>> > > index 00..59647b22f8
>> > > --- /dev/null
>> > > +++
>> > > b/meta/recipes-core/systemd/systemd/0033-basic-macros-
>> >
>> > rename-noreturn-into-
>> >
>> > > _noreturn_-8456.patch @@ -0,0 +1,203 @@
>> > > +From 848e863acc51ecfb0f3955c498874588201d9130 Mon Sep 17 00:00:00 2001
>> > > +From: Franck Bui <f...@suse.com>
>> > > +Date: Thu, 15 Mar 2018 06:23:46 +0100
>> > > +Subject: [PATCH] basic/macros: rename noreturn into _noreturn_ (#8456)
>> > > +MIME-Version: 1.0
>> > > +Content-Type: text/plain; charset=UTF-8
>> > > +Content-Transfer-Encoding: 8bit
>> > > +
>> > > +"noreturn" is reserved and can be used in other header files we
>> > > include:
>> > > +
>> > > +  [   16s] In file included fr

Re: [OE-core] [PATCH] systemd: backport patch to fix build when gcrypt is enabled

[Andrea Galbusera]

Hi Mark!

Il mer 9 mag 2018, 15:56 Mark Asselstine <mark.asselst...@windriver.com> ha
scritto:

> On Wednesday, May 9, 2018 8:16:08 AM EDT Andrea Galbusera wrote:
> > When gcrypt support is present in PACKAGECONFIG, build fails due to the
> bug
> > reported in [1]. Since this is already solved upstream, this commit
> > backports the corresponding patch.
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893602
> >
> > Signed-off-by: Andrea Galbusera <giz...@gmail.com>
>
> Thanks Andrea, I can confirm this fixes a build failure we were seeing as
> well.
>

Thanks for further testing the patch so quickly!

Out of curiosity... Are you also enabling gcrypt support to workaround the
implict dependency resolved used to have upon gcrypt in the past? It took
me a few hours to figure out what was specific in my configuration, since
this bug was obviously not exposed in configurations currently built by the
autobuilders!

As a side note, I know there is a newer released version of systemd (238),
but upgrading such a complex recipe was not an option for me in the short.
I'm CC-ing the recipe's maintainer here, in case there's already an effort
to upgrade to 238...


> Mark
>
> > ---
> >  ...rename-noreturn-into-_noreturn_-8456.patch | 203 ++
> >  meta/recipes-core/systemd/systemd_237.bb  |   1 +
> >  2 files changed, 204 insertions(+)
> >  create mode 100644
> > meta/recipes-core/systemd/systemd/0033-basic-macros-
> rename-noreturn-into-_n
> > oreturn_-8456.patch
> >
> > diff --git
> > a/meta/recipes-core/systemd/systemd/0033-basic-macros-
> rename-noreturn-into-
> > _noreturn_-8456.patch
> > b/meta/recipes-core/systemd/systemd/0033-basic-macros-
> rename-noreturn-into-
> > _noreturn_-8456.patch new file mode 100644
> > index 00..59647b22f8
> > --- /dev/null
> > +++
> > b/meta/recipes-core/systemd/systemd/0033-basic-macros-
> rename-noreturn-into-
> > _noreturn_-8456.patch @@ -0,0 +1,203 @@
> > +From 848e863acc51ecfb0f3955c498874588201d9130 Mon Sep 17 00:00:00 2001
> > +From: Franck Bui <f...@suse.com>
> > +Date: Thu, 15 Mar 2018 06:23:46 +0100
> > +Subject: [PATCH] basic/macros: rename noreturn into _noreturn_ (#8456)
> > +MIME-Version: 1.0
> > +Content-Type: text/plain; charset=UTF-8
> > +Content-Transfer-Encoding: 8bit
> > +
> > +"noreturn" is reserved and can be used in other header files we include:
> > +
> > +  [   16s] In file included from /usr/include/gcrypt.h:30:0,
> > +  [   16s]  from ../src/journal/journal-file.h:26,
> > +  [   16s]  from ../src/journal/journal-vacuum.c:31:
> > +  [   16s] /usr/include/gpg-error.h:1544:46: error: expected ‘,’ or ‘;’
> > before ‘)’ token +  [   16s]  void gpgrt_log_bug (const char *fmt, ...)
>
> > GPGRT_ATTR_NR_PRINTF(1,2); +
> > +Here we include grcrypt.h (which in turns include gpg-error.h) *after*
> we
> > +"noreturn" was defined in macro.h.
> > +---
> > + src/basic/log.c |  4 ++--
> > + src/basic/log.h |  4 ++--
> > + src/basic/macro.h   | 19 +--
> > + src/basic/process-util.c|  2 +-
> > + src/basic/process-util.h|  2 +-
> > + src/core/main.c |  4 ++--
> > + src/journal/test-journal-interleaving.c |  2 +-
> > + src/shared/pager.c  |  2 +-
> > + src/udev/collect/collect.c  |  2 +-
> > + 9 files changed, 20 insertions(+), 21 deletions(-)
> > +
> > +Upstream-Status: Backport [https://github.com/systemd/systemd/pull/8456
> ]
> > +
> > +diff --git a/src/basic/log.c b/src/basic/log.c
> > +index 7a7f2cbec..16a2431c5 100644
> > +--- a/src/basic/log.c
> >  b/src/basic/log.c
> > +@@ -814,7 +814,7 @@ static void log_assert(
> > + log_dispatch_internal(level, 0, file, line, func, NULL, NULL,
> > NULL, NULL, buffer); + }
> > +
> > +-noreturn void log_assert_failed_realm(
> > ++_noreturn_ void log_assert_failed_realm(
> > + LogRealm realm,
> > + const char *text,
> > + const char *file,
> > +@@ -826,7 +826,7 @@ noreturn void log_assert_failed_realm(
> > + abort();
> > + }
> > +
> > +-noreturn void log_assert_failed_unreachable_realm(
> > ++_noreturn_ void log_assert_failed_unreachable_realm(
> > + LogRealm realm,
> > + const char *text,
> > + const char *file,
> >

[OE-core] [PATCH] systemd: backport patch to fix build when gcrypt is enabled

[Andrea Galbusera]

When gcrypt support is present in PACKAGECONFIG, build fails due to the bug
reported in [1]. Since this is already solved upstream, this commit backports
the corresponding patch.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893602

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 ...rename-noreturn-into-_noreturn_-8456.patch | 203 ++
 meta/recipes-core/systemd/systemd_237.bb  |   1 +
 2 files changed, 204 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-_noreturn_-8456.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-_noreturn_-8456.patch
 
b/meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-_noreturn_-8456.patch
new file mode 100644
index 00..59647b22f8
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-_noreturn_-8456.patch
@@ -0,0 +1,203 @@
+From 848e863acc51ecfb0f3955c498874588201d9130 Mon Sep 17 00:00:00 2001
+From: Franck Bui <f...@suse.com>
+Date: Thu, 15 Mar 2018 06:23:46 +0100
+Subject: [PATCH] basic/macros: rename noreturn into _noreturn_ (#8456)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+"noreturn" is reserved and can be used in other header files we include:
+
+  [   16s] In file included from /usr/include/gcrypt.h:30:0,
+  [   16s]  from ../src/journal/journal-file.h:26,
+  [   16s]  from ../src/journal/journal-vacuum.c:31:
+  [   16s] /usr/include/gpg-error.h:1544:46: error: expected ‘,’ or ‘;’ before 
‘)’ token
+  [   16s]  void gpgrt_log_bug (const char *fmt, ...)
GPGRT_ATTR_NR_PRINTF(1,2);
+
+Here we include grcrypt.h (which in turns include gpg-error.h) *after* we
+"noreturn" was defined in macro.h.
+---
+ src/basic/log.c |  4 ++--
+ src/basic/log.h |  4 ++--
+ src/basic/macro.h   | 19 +--
+ src/basic/process-util.c|  2 +-
+ src/basic/process-util.h|  2 +-
+ src/core/main.c |  4 ++--
+ src/journal/test-journal-interleaving.c |  2 +-
+ src/shared/pager.c  |  2 +-
+ src/udev/collect/collect.c  |  2 +-
+ 9 files changed, 20 insertions(+), 21 deletions(-)
+
+Upstream-Status: Backport [https://github.com/systemd/systemd/pull/8456]
+
+diff --git a/src/basic/log.c b/src/basic/log.c
+index 7a7f2cbec..16a2431c5 100644
+--- a/src/basic/log.c
 b/src/basic/log.c
+@@ -814,7 +814,7 @@ static void log_assert(
+ log_dispatch_internal(level, 0, file, line, func, NULL, NULL, NULL, 
NULL, buffer);
+ }
+ 
+-noreturn void log_assert_failed_realm(
++_noreturn_ void log_assert_failed_realm(
+ LogRealm realm,
+ const char *text,
+ const char *file,
+@@ -826,7 +826,7 @@ noreturn void log_assert_failed_realm(
+ abort();
+ }
+ 
+-noreturn void log_assert_failed_unreachable_realm(
++_noreturn_ void log_assert_failed_unreachable_realm(
+ LogRealm realm,
+ const char *text,
+ const char *file,
+diff --git a/src/basic/log.h b/src/basic/log.h
+index efcf0f1bf..314be128a 100644
+--- a/src/basic/log.h
 b/src/basic/log.h
+@@ -186,7 +186,7 @@ int log_dump_internal(
+ char *buffer);
+ 
+ /* Logging for various assertions */
+-noreturn void log_assert_failed_realm(
++_noreturn_ void log_assert_failed_realm(
+ LogRealm realm,
+ const char *text,
+ const char *file,
+@@ -195,7 +195,7 @@ noreturn void log_assert_failed_realm(
+ #define log_assert_failed(text, ...) \
+ log_assert_failed_realm(LOG_REALM, (text), __VA_ARGS__)
+ 
+-noreturn void log_assert_failed_unreachable_realm(
++_noreturn_ void log_assert_failed_unreachable_realm(
+ LogRealm realm,
+ const char *text,
+ const char *file,
+diff --git a/src/basic/macro.h b/src/basic/macro.h
+index 95be63a20..8911edfc4 100644
+--- a/src/basic/macro.h
 b/src/basic/macro.h
+@@ -53,6 +53,15 @@
+ #else
+ #define _fallthrough_
+ #endif
++/* Define C11 noreturn without  and even on older gcc
++ * compiler versions */
++#ifndef _noreturn_
++#if __STDC_VERSION__ >= 201112L
++#define _noreturn_ _Noreturn
++#else
++#define _noreturn_ __attribute__((noreturn))
++#endif
++#endif
+ 
+ /* Temporarily disable some warnings */
+ #define DISABLE_WARNING_DECLARATION_AFTER_STATEMENT \
+@@ -414,16 +423,6 @@ static inline unsigned long ALIGN_POWER2(unsigned long u) 
{
+ #endif
+ #endif
+ 
+-/* Define C11 noreturn without  and even on older gcc
+- * compiler versions */
+-#ifndef noreturn
+-#if __STDC_VERSION__ >= 201112L
+-#define noreturn _Noreturn
+-#else
+-#define noreturn __attribute__((noreturn))
+-#endif
+-#endif
+-
+ #define 

Re: [OE-core] Fwd: confirm 6bb527bbc2e6d9a2a2165aa081ea1271ece07fe8

[Andrea Galbusera]

On Thu, Mar 29, 2018 at 11:56 PM, Martin Jansa  wrote:
> I got the same today.

Me too!

>
> On Thu, Mar 29, 2018 at 11:51 PM, Trevor Woerner  wrote:
>>
>> uhhh gmail is on the bad list?
>> anyone else get one of these?
>>
>>
>> -- Forwarded message --
>> From: 
>> Date: Thu, Mar 29, 2018 at 8:13 AM
>> Subject: confirm
>> To: twoer...@gmail.com
>>
>>
>> Your membership in the mailing list Openembedded-core has been
>> disabled due to excessive bounces The last bounce received from you
>> was dated 29-Mar-2018.  You will not get any more messages from this
>> list until you re-enable your membership.  You will receive 3 more
>> reminders like this before your membership in the list is deleted.
>>
>>
>> --
>> ___
>> 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] bitbake.conf: add tools required by testimage to HOSTTOOLS conditionally

[Andrea Galbusera]

On Sun, Oct 15, 2017 at 4:01 AM, Denys Dmytriyenko <de...@denix.org> wrote:
> On Sat, Oct 14, 2017 at 10:53:03PM +0200, Andrea Galbusera wrote:
>> On Sat, Sep 30, 2017 at 10:15 AM, Chen Qi <qi.c...@windriver.com> wrote:
>> > Add tools required by testimage to HOSTTOOLS only when testimage is
>> > inherited. These tools, as described in the comment, are only required
>> > by the testimage task. So this change should not have negtive effect.
>> > This would also solve build error on hosts which miss some tool such as 
>> > scp.
>> >
>> > Signed-off-by: Chen Qi <qi.c...@windriver.com>
>> > ---
>> >  meta/conf/bitbake.conf | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> > index f41680b..94c1f27 100644
>> > --- a/meta/conf/bitbake.conf
>> > +++ b/meta/conf/bitbake.conf
>> > @@ -484,7 +484,7 @@ HOSTTOOLS += " \
>> >  "
>> >
>> >  # Tools needed to run testimage runtime image testing
>> > -HOSTTOOLS += "ip ping ps scp ssh stty"
>> > +HOSTTOOLS += "${@['', 'ip ping ps scp ssh 
>> > stty'][bb.data.inherits_class('testimage', d)]}"
>> >
>> >  # Link to these if present
>> >  HOSTTOOLS_NONFATAL += "aws ccache gcc-ar gpg ld.bfd ld.gold nc sftp socat 
>> > sudo"
>> > --
>> > 1.9.1
>> >
>> > --
>> > ___
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>> This one is breaking any recipe that fetches from git repo with
>> 'protocol=ssh' in its SRC_URI... I verified that reverting this one
>> restores the usual fetcher behaviour. Should ssh be added to HOSTTOOLS
>> unconditionally or is there any other way to approach it?
>
> There's an entire thread discussing it here:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143279.html

Thank you Denys for pointing to the full discussion: it was not
threaded together with the initial mail that submitted the patch, then
I missed it... :-/
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] bitbake.conf: add tools required by testimage to HOSTTOOLS conditionally

[Andrea Galbusera]

On Sat, Sep 30, 2017 at 10:15 AM, Chen Qi  wrote:
> Add tools required by testimage to HOSTTOOLS only when testimage is
> inherited. These tools, as described in the comment, are only required
> by the testimage task. So this change should not have negtive effect.
> This would also solve build error on hosts which miss some tool such as scp.
>
> Signed-off-by: Chen Qi 
> ---
>  meta/conf/bitbake.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index f41680b..94c1f27 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -484,7 +484,7 @@ HOSTTOOLS += " \
>  "
>
>  # Tools needed to run testimage runtime image testing
> -HOSTTOOLS += "ip ping ps scp ssh stty"
> +HOSTTOOLS += "${@['', 'ip ping ps scp ssh 
> stty'][bb.data.inherits_class('testimage', d)]}"
>
>  # Link to these if present
>  HOSTTOOLS_NONFATAL += "aws ccache gcc-ar gpg ld.bfd ld.gold nc sftp socat 
> sudo"
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

This one is breaking any recipe that fetches from git repo with
'protocol=ssh' in its SRC_URI... I verified that reverting this one
restores the usual fetcher behaviour. Should ssh be added to HOSTTOOLS
unconditionally or is there any other way to approach it?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] non uniform directories permissions in sstate-cache

[Andrea Galbusera]

Recent posts on both Yocto's ML and here mentioned this issue, but I prefer
to post in a new thread, since it's possible that the main focus of those
thread (sharing sstate-cache between multiple users) might somewhat have
shadowed what IMHO seems indeed an issue with directories permissions in
sstate-cache.

What I observed on at least three different build hosts is quite simple:
the permissions directories in sstate-cache/ are not uniform. Most of them
are 775, but some are 755. This happens with fresh builds (all by the same
user) and can be observed on master and morty branches for sure (not
verified with pyro).

Anyone else seeing this? It might have been unnoticed, or you might have an
explanation to state this is normal, but I'd be very surprised if you told
me I'm alone in seeing this. Between the hosts that showed this behaviour I
have Ubuntu 16.04 boxes (either baremetal or Virtualbox VMs) and the
crops/poky-container running on OSX native docker implementation.

After noticing this, I got a look at sstate.bbclass, which I believe is the
code responsible for actually creating those hierarchies. The following
snippet seems to be the place where, regardless of the process' umask,
bitbake should ensure sstate-cache subdirs are created with 775 permissions
(by changing the process' umask to 002). Am I missing other places where
this is handled indeed?

   omask = os.umask(0o002)
   if omask != 0o002:
  bb.note("Using umask 0o002 (not %0o) for sstate packaging" % omask)
   sstate_package(shared_state, d)
   os.umask(omask)

Now, I'd don't feel confident enough with the code to push my investigation
further, than I'm writing this to hopefully have someone more experienced
looking at it and help figuring out what's going on.

Any thought? Should I file it as a bug?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] [openembedded-core] branch master updated (cc319b6 -> 2ebbeb6)

[Andrea Galbusera]

Hi!

On Tue, Sep 12, 2017 at 12:58 PM, Martin Jansa 
wrote:

> Hi,
>
> I don't see any obvious change in this update which should cause this, but
> rebuilding my image for raspberrypi3-64 after this update (the previous
> image was built without errors) shows:
>
> NOTE: Running task 417 of 6399 (/OE/build/owpb/webos-ports/
> meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_
> validate_branches)
> NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
> do_validate_branches: Started
> 
> NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
> do_validate_branches: Succeeded
> NOTE: Running task 434 of 6399 (/OE/build/owpb/webos-ports/
> meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_kernel_
> metadata)
> NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
> do_kernel_metadata: Started
> ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
> do_kernel_metadata: Could not locate BSP definition for
> raspberrypi3-64/standard and no defconfig was provided
> NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
> do_kernel_metadata: Succeeded
> ...
> NOTE: Running task 454 of 6399 (/OE/build/owpb/webos-ports/
> meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_patch)
> NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
> do_patch: Started
> NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
> do_patch: Succeeded
> NOTE: Running task 491 of 6399 (/OE/build/owpb/webos-ports/
> meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_kernel_
> configme)
> NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
> do_kernel_configme: Started
> ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
> do_kernel_configme: [ERROR]: no configuration queue found in outdir
> (.kernel-meta)
>
>  scc [--help] [--configs] [--force] [-i] [-w] [--cmds  list>] [-o outdir:] [-D=] [-I] [-v]
> infiles
>
>   --help:  This message
>   --force: force overwrite output file if it already exists
>   --cmds:  list of supported commands. If not passed, all found
> commands are loaded,
>valid commands are: patch, kconf, branch, define
>   --configs:   Output the list of compiled configuration fragments (if
> available), -o  is
>used to locate the configuration options
>   -D:  define  to  which will be available to sub
> scripts
>   -I:  include path  will be searched for files
>   -i:  leave intermediate files on failure
>   -w:  only warn on missing files
>   -v:  verbose output
>   -o:  output directory and artifacts. artifacts follow the
> colon and ar a comma
>separated list of:
>meta:  full meta-series (patches, config, branches,
> etc)
>cfg:   configure fragment queue
>patch: patch queue
>
>   infiles  files to preprocess, and output into outfile or stdout
> ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
> do_kernel_configme: Could not find configuration queue
> (.kernel-meta/config.queue)
> ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
> do_kernel_configme: Function failed: do_kernel_configme (log file is
> located at /OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_
> 64-webos-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/temp/
> log.do_kernel_configme.19498)
> ERROR: Logfile of failure stored in: /OE/build/owpb/webos-ports/
> tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.41+
> gitAUTOINC+4153f509b4-r0/temp/log.do_kernel_configme.19498
> Log data follows:
> | DEBUG: Executing shell function do_kernel_configme
> | ERROR: [ERROR]: no configuration queue found in outdir (.kernel-meta)
> |
> |  scc [--help] [--configs] [--force] [-i] [-w] [--cmds  list>] [-o outdir:] [-D=] [-I] [-v]
> infiles
> |
> |   --help:  This message
> |   --force: force overwrite output file if it already exists
> |   --cmds:  list of supported commands. If not passed, all found
> commands are loaded,
> |valid commands are: patch, kconf, branch, define
> |   --configs:   Output the list of compiled configuration fragments
> (if available), -o  is
> |used to locate the configuration options
> |   -D:  define  to  which will be available to
> sub scripts
> |   -I:  include path  will be searched for files
> |   -i:  leave intermediate files on failure
> |   -w:  only warn on missing files
> |   -v:  verbose output
> |   -o:  output directory and artifacts. artifacts follow the
> colon and ar a comma
> |separated list of:
> |meta:  

Re: [OE-core] [PATCH 1/3] mesa: Support building without opengl

[Andrea Galbusera]

On Mon, Sep 4, 2017 at 10:15 AM, Jussi Kukkonen <jussi.kukko...@intel.com>
wrote:

> On 4 September 2017 at 10:49, Andrea Galbusera <giz...@gmail.com> wrote:
>
>> | configure: error: GLX cannot be built without OpenGL
>> | NOTE: The following config.log files may provide further information.
>> | NOTE: /home/gizero/work/smartliving/distro/repo-master/build-poky/
>> tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_
>> 17.1.7-r0/build/config.log
>> | ERROR: configure failed
>> | WARNING: exit code 1 from a shell command.
>> | ERROR: Function failed: do_configure (log file is located at
>> /home/gizero/work/smartliving/distro/repo-master/build-poky/
>> tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_
>> 17.1.7-r0/temp/log.do_configu
>> re.1391)
>> ERROR: Task (/home/gizero/work/smartliving/distro/repo-master/build-
>> poky/conf/../../layers/poky/meta/recipes-graphics/mesa/mesa-gl_17.1.7.bb:
>> do_configure) failed with exit code '1'
>>
>> This doesn't seem to be related to the bbappend for mesa-gl that is
>> present in meta-raspberrypi, which merely appends "gbm" to PACKAGECONFIG
>> for rpi machines (bitbake still complains with this removed). Instead,
>> reverting this commit takes the build back to green light.
>>
>
> Sorry, I must have not tested mesa-gl with the version of the patch that I
> sent. Sending a fix after a quick test (mesa-gl seems to be missing
> "opengl" from PACKAGECONFIG).
>

Positively build tested the patch you just sent: it fixes it! Thanks!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] mesa: Support building without opengl

[Andrea Galbusera]

Hi,

On Mon, Aug 28, 2017 at 2:46 PM, Jussi Kukkonen 
wrote:

> mesa can build certain things without opengl: most importantly vulkan
> drivers.
>
> Add comments on the dependencies between the packageconfigs. Also add
> a few dependencies to packageconfigs. Modify default packageconfig to
> do the reasonable thing based on distro features.
>
> Add a backported patch to fix the build with --disable-opengl. Fix
> do_install_append() so it works even if dri drivers are not built.
>
> Signed-off-by: Jussi Kukkonen 
> ---
>  .../0001-configure.ac-Always-check-for-expat.patch | 51
> ++
>  meta/recipes-graphics/mesa/mesa.inc| 23 +++---
>  meta/recipes-graphics/mesa/mesa_17.1.7.bb  |  1 +
>  3 files changed, 68 insertions(+), 7 deletions(-)
>  create mode 100644 meta/recipes-graphics/mesa/files/0001-configure.ac-
> Always-check-for-expat.patch
>
> diff --git 
> a/meta/recipes-graphics/mesa/files/0001-configure.ac-Always-check-for-expat.patch
> b/meta/recipes-graphics/mesa/files/0001-configure.ac-
> Always-check-for-expat.patch
> new file mode 100644
> index 000..4753c49
> --- /dev/null
> +++ b/meta/recipes-graphics/mesa/files/0001-configure.ac-
> Always-check-for-expat.patch
> @@ -0,0 +1,51 @@
> +From 1f7d752193f02d15d5923cee992e8f46d4c6df1b Mon Sep 17 00:00:00 2001
> +From: Jussi Kukkonen 
> +Date: Mon, 28 Aug 2017 13:51:49 +0300
> +Subject: [PATCH] configure.ac: Always check for expat
> +
> +expat was not checked if dri was not built leading to build failure
> +in vulkan driver: backport a fix (a combination of multiple commits
> +that should end up in 17.3).
> +
> +Upstream-Status: Backport
> +Signed-off-by: Jussi Kukkonen 
> +---
> + configure.ac | 15 ++-
> + 1 file changed, 6 insertions(+), 9 deletions(-)
> +
> +diff --git a/configure.ac b/configure.ac
> +index fd346c8aa2..662faecefa 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -1777,6 +1777,12 @@ if test "x$with_dri_drivers" = xno; then
> + with_dri_drivers=''
> + fi
> +
> ++# Check for expat
> ++PKG_CHECK_MODULES([EXPAT], [expat])
> ++PKG_CHECK_MODULES([EXPAT], [expat],,
> ++[PKG_CHECK_MODULES([EXPAT], [expat21])]
> ++)
> ++
> + dnl If $with_dri_drivers is yes, drivers will be added through
> + dnl platform checks. Set DEFINES and LIB_DEPS
> + if test "x$enable_dri" = xyes; then
> +@@ -1810,15 +1816,6 @@ if test "x$enable_dri" = xyes; then
> + with_dri_drivers="i915 i965 nouveau r200 radeon swrast"
> + fi
> +
> +-# Check for expat
> +-PKG_CHECK_MODULES([EXPAT], [expat], [],
> +-# expat version 2.0 and earlier do not provide expat.pc
> +-[AC_CHECK_HEADER([expat.h],[],
> +- [AC_MSG_ERROR([Expat headers required for DRI
> not found])])
> +- AC_CHECK_LIB([expat],[XML_ParserCreate],[],
> +- [AC_MSG_ERROR([Expat library required for DRI not
> found])])
> +- EXPAT_LIBS="-lexpat"])
> +-
> + # put all the necessary libs together
> + DRI_LIB_DEPS="$DRI_LIB_DEPS $SELINUX_LIBS $LIBDRM_LIBS $EXPAT_LIBS
> -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> + fi
> +--
> +2.14.1
> +
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index 3bb3cf4..4f31ed2 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -20,7 +20,7 @@ PROVIDES = "virtual/libgl virtual/libgles1
> virtual/libgles2 virtual/egl virtual/
>
>  inherit autotools pkgconfig gettext distro_features_check
>
> -REQUIRED_DISTRO_FEATURES = "opengl"
> +ANY_OF_DISTRO_FEATURES = "opengl vulkan"
>
>  PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)} \
> ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'drm', '',
> d)}"
> @@ -32,20 +32,25 @@ EXTRA_OECONF = "--enable-shared-glapi \
>  --with-llvm-prefix=${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}
> \
>  --with-platforms='${PLATFORMS}'"
>
> -PACKAGECONFIG ??= "gbm egl gles dri \
> -   ${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11
> vulkan', d)} \
> -   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan',
> 'dri3', '', d)} \
> -   "
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland
> vulkan', d)} \
> +   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'opengl egl gles gbm dri', '', d)} \
> +   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
> 'x11', '', d)} \
> +   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan',
> 'dri3', '', d)} \
> +  "
> +
> +# "gbm" requires "dri", "opengl"
>  PACKAGECONFIG[gbm] = "--enable-gbm,--disable-gbm"
>
>  X11_DEPS = "xf86driproto glproto virtual/libx11 libxext libxxf86vm
> libxdamage libxfixes"
> +# "x11" requires "opengl"
>  PACKAGECONFIG[x11] = 

Re: [OE-core] [PATCH] mesa: update to 17.1.6

[Andrea Galbusera]

On Thu, Aug 10, 2017 at 11:37 AM, Andreas Müller <
schnitzelt...@googlemail.com> wrote:

> Optional installation of khrplatform.h was implemented upstream by a
> slightly
> different approach -> 0001-mapi-Only-install-khrplat
> form.h-with-EGL-or-GLES.patch
> can be removed.


> Signed-off-by: Andreas Müller 
>

LGTM. Being reporting the issue that originated the here removed patch by
Jussi, I build tested this commit on the original setup with
meta-raspberrypi and everything still looks good.

---
>  ...ly-install-khrplatform.h-with-EGL-or-GLES.patch | 52
> --
>  .../mesa/{mesa-gl_17.1.5.bb => mesa-gl_17.1.6.bb}  |  0
>  .../mesa/{mesa_17.1.5.bb => mesa_17.1.6.bb}|  5 +--
>  3 files changed, 2 insertions(+), 55 deletions(-)
>  delete mode 100644 meta/recipes-graphics/mesa/fil
> es/0001-mapi-Only-install-khrplatform.h-with-EGL-or-GLES.patch
>  rename meta/recipes-graphics/mesa/{mesa-gl_17.1.5.bb => mesa-gl_17.1.6.bb}
> (100%)
>  rename meta/recipes-graphics/mesa/{mesa_17.1.5.bb => mesa_17.1.6.bb}
> (81%)
>
> diff --git a/meta/recipes-graphics/mesa/files/0001-mapi-Only-install-kh
> rplatform.h-with-EGL-or-GLES.patch b/meta/recipes-graphics/mesa/f
> iles/0001-mapi-Only-install-khrplatform.h-with-EGL-or-GLES.patch
> deleted file mode 100644
> index be61e2e..000
> --- a/meta/recipes-graphics/mesa/files/0001-mapi-Only-install-kh
> rplatform.h-with-EGL-or-GLES.patch
> +++ /dev/null
> @@ -1,52 +0,0 @@
> -From 922cb47a5b950ee5545a7a3cb4cd9a88a8b15054 Mon Sep 17 00:00:00 2001
> -From: Jussi Kukkonen 
> -Date: Wed, 12 Jul 2017 12:21:29 +0300
> -Subject: [PATCH] mapi: Only install khrplatform.h with EGL or GLES
> -
> -When mesa is built with "--disable-egl --disable-gles1
> ---disable-gles2" the KHR platform headers are not needed.
> -
> -Not installing the header when not needed allows using mesa for GL
> -and another implementation for GLES+EGL (as is done in practice with
> -userland on raspberrypi).
> -
> -Upstream-Status: Pending [waiting for test results before sending]
> -Signed-off-by: Jussi Kukkonen 
> 
> - src/mapi/Makefile.am | 9 -
> - 1 file changed, 8 insertions(+), 1 deletion(-)
> -
> -diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> -index 9ff70a14fd..94c77fb82c 100644
>  a/src/mapi/Makefile.am
> -+++ b/src/mapi/Makefile.am
> -@@ -188,6 +188,8 @@ es1api_libGLESv1_CM_la_LDFLAGS = \
> -   $(LD_NO_UNDEFINED)
> -
> - es1api_libGLESv1_CM_la_LIBADD += shared-glapi/libglapi.la
> -+
> -+khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
> - endif
> -
> - es1api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml
> $(glapi_gen_mapi_deps)
> -@@ -233,6 +235,12 @@ es2api_libGLESv2_la_LDFLAGS = \
> -   $(LD_NO_UNDEFINED)
> -
> - es2api_libGLESv2_la_LIBADD += shared-glapi/libglapi.la
> -+
> -+khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
> -+endif
> -+
> -+if HAVE_EGL
> -+khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
> - endif
> -
> - es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml
> $(glapi_gen_mapi_deps)
> -@@ -243,4 +251,3 @@ es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml
> $(glapi_gen_mapi_deps)
> - include $(top_srcdir)/install-lib-links.mk
> -
> - khrdir = $(includedir)/KHR
> --khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
> ---
> -2.13.2
> -
> diff --git a/meta/recipes-graphics/mesa/mesa-gl_17.1.5.bb
> b/meta/recipes-graphics/mesa/mesa-gl_17.1.6.bb
> similarity index 100%
> rename from meta/recipes-graphics/mesa/mesa-gl_17.1.5.bb
> rename to meta/recipes-graphics/mesa/mesa-gl_17.1.6.bb
> diff --git a/meta/recipes-graphics/mesa/mesa_17.1.5.bb
> b/meta/recipes-graphics/mesa/mesa_17.1.6.bb
> similarity index 81%
> rename from meta/recipes-graphics/mesa/mesa_17.1.5.bb
> rename to meta/recipes-graphics/mesa/mesa_17.1.6.bb
> index 36b0377..111c73a 100644
> --- a/meta/recipes-graphics/mesa/mesa_17.1.5.bb
> +++ b/meta/recipes-graphics/mesa/mesa_17.1.6.bb
> @@ -5,14 +5,13 @@ SRC_URI = "https://mesa.freedesktop.org/
> archive/mesa-${PV}.tar.xz \
> file://disable-asm-on-non-gcc.patch \
> file://0001-Use-wayland-scanner-in-the-path.patch \
> file://0002-hardware-gloat.patch \
> -   file://0001-mapi-Only-install-khrplatform.h-with-EGL-or-GLES.patch
> \
> file://vulkan-mkdir.patch \
> file://llvm-config-version.patch \
> file://0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch \
> file://0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch \
>  "
> -SRC_URI[md5sum] = "6cf936fbcaadd98924298a7009e8265d"
> -SRC_URI[sha256sum] = "378516b171712687aace4c7ea8b37
> c85895231d7a6d61e1e27362cf6034fded9"
> +SRC_URI[md5sum] = "54758bf842f9ea53c8b57cce4311b87e"
> +SRC_URI[sha256sum] = "0686deadde1f126b20aa67e47e8c5
> 0502043eee4ecdf60d5009ffda3cebfee50"
>
>  #because we cannot rely on the fact that all apps will use pkgconfig,
>  #make eglplatform.h independent of 

[OE-core] [PATCH 2/2] scripts/oe-publish-sdk: use hook to call git update-server-info

[Andrea Galbusera]

The author's initial intent was to use a git hook to automatically call
update-server-info, but the wrong hook type was chosen (post-update). A
post-commit one will do the job, hence allowing to drop the explicit call to
update-server-info.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 scripts/oe-publish-sdk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/oe-publish-sdk b/scripts/oe-publish-sdk
index 9f7963c..ee33acf 100755
--- a/scripts/oe-publish-sdk
+++ b/scripts/oe-publish-sdk
@@ -114,9 +114,9 @@ def publish(args):
 
 # Setting up the git repo
 if not is_remote:
-cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; mv .git/hooks/post-update.sample .git/hooks/post-update; echo 
"*.pyc\n*.pyo\npyshtables.py" > .gitignore; fi; git add -A .; git config 
user.email "o...@oe.oe" && git config user.name "OE" && git commit -q -m "init 
repo" || true; git update-server-info' % (destination, destination)
+cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; cp .git/hooks/post-update.sample .git/hooks/post-commit; echo 
"*.pyc\n*.pyo\npyshtables.py" > .gitignore; fi; git add -A .; git config 
user.email "o...@oe.oe" && git config user.name "OE" && git commit -q -m "init 
repo" || true' % (destination, destination)
 else:
-cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; mv .git/hooks/post-update.sample 
.git/hooks/post-update; echo '*.pyc\n*.pyo\npyshtables.py' > .gitignore; fi; 
git add -A .; git config user.email 'o...@oe.oe' && git config user.name 'OE' 
&& git commit -q -m \"init repo\" || true; git update-server-info'" % (host, 
destdir, destdir)
+cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; cp .git/hooks/post-update.sample 
.git/hooks/post-commit; echo '*.pyc\n*.pyo\npyshtables.py' > .gitignore; fi; 
git add -A .; git config user.email 'o...@oe.oe' && git config user.name 'OE' 
&& git commit -q -m \"init repo\" || true'" % (host, destdir, destdir)
 ret = subprocess.call(cmd, shell=True)
 if ret == 0:
 logger.info('SDK published successfully')
-- 
2.7.4

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

[OE-core] [PATCH 1/2] devtool: sdk-update: fix pulling updates from git

[Andrea Galbusera]

Commit 4657bc9d165e51981e034e73e7b92552e873eef7 replaced the git pull logic with
the git fetch + git reset --hard combo, but resetting to HEAD does not really
pull in new commits from remote... Replace with resetting to the upstream branch
instead.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 scripts/lib/devtool/sdk.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index e8bf0ad..f46577c 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -155,7 +155,7 @@ def sdk_update(args, config, basepath, workspace):
 if os.path.exists(os.path.join(basepath, 'layers/.git')):
 out = subprocess.check_output("git status --porcelain", 
shell=True, cwd=layers_dir)
 if not out:
-ret = subprocess.call("git fetch --all; git reset --hard", 
shell=True, cwd=layers_dir)
+ret = subprocess.call("git fetch --all; git reset --hard 
@{u}", shell=True, cwd=layers_dir)
 else:
 logger.error("Failed to update metadata as there have been 
changes made to it. Aborting.");
 logger.error("Changed files:\n%s" % out);
-- 
2.7.4

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

[OE-core] android-tools related warnings in (updated) eSDK

[Andrea Galbusera]

When upgrading an eSDK (via devtool sdk-update) from a project that
includes meta-oe in the stack, some files listed in android-tools' SRC_URI,
most notably patches and systemd service file got removed from the eSDK
copy of metadata during the update, leading bitbake to start warning about
not being able to verify the checksum for those files (those files are
indeed missing as shown below).

Here is the log from bitbake:

WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry remove-selinux-android.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry use-capability.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry use-local-socket.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry preserve-ownership.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry mkbootimg-Add-dt-parameter-to-specify-DT-image.patch: file
could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry remove-bionic-android.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry define-shell-command.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry implicit-declaration-function-strlcat-strlcopy.patch: file
could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry fix-big-endian-build.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools-native
SRC_URI entry android-tools-adbd.service: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry remove-selinux-android.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry use-capability.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry use-local-socket.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry preserve-ownership.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry mkbootimg-Add-dt-parameter-to-specify-DT-image.patch: file
could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry remove-bionic-android.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry define-shell-command.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry implicit-declaration-function-strlcat-strlcopy.patch: file
could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry fix-big-endian-build.patch: file could not be found
WARNING:
/home/vagrant/poky_sdk/layers/meta-oe/recipes-devtools/android-tools/
android-tools_5.1.1.r37.bb: Unable to get checksum for android-tools
SRC_URI entry android-tools-adbd.service: file could not be found

...and the metadata files:

$ find poky_sdk/layers/meta-oe/recipes-devtools/android-tools/android-tools

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Tue, Jul 11, 2017 at 10:06 AM, Jussi Kukkonen <jussi.kukko...@intel.com>
wrote:

> On 10 July 2017 at 17:47, Andrea Galbusera <giz...@gmail.com> wrote:
>
>> During bisection the failing task changed from do_prepare_recipe_sysroot
>> to do_compile with the log below. I have no idea if these things do relate
>> themselves, but if not, I was not able to figure it out while bisecting.
>>
>> | In file included from /home/gizero/work/smartliving/
>> distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4
>> -poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/incl
>> ude/epoxy/egl.h:46:0,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.h:32,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.c:24:
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c: In function
>> 'gdk_wayland_gl_context_realize':
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c:179:43:
>> error: expected expression before 'EGLContext'
>> |  : EGL_NO_CONTEXT,
>> |^
>>
>
> Your bisect seems valid: gtk+3 uses a define that comes from epoxy and was
> changed in the update. The new define uses a EGL_CAST() macro that was
> added to eglplatform.h at the same time. mesa has updated their
> eglplatform.h so it all seems to work, but userland does not seem to have
> this macro?
>
> There's probably more to the story (since the error is not about implicit
> EGL_CAST() as one would expect). My first suggestion would be that userland
> eglplatform.h is updated to match current Khronos registry or at least to
> include the EGL_CAST definition.
>
>
Can anyone of you guys with deep understanding in this matter help with
[1]. I posted a pull request on RPi userland upstream backporting changes
to eglplatform.h from mesa that seems relevant to fix builds for libepoxy
and gtk+3 but maintainers arguments needs more knowledge than I have...

[1] https://github.com/raspberrypi/userland/pull/407
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] mesa: Improve Khronos header handling

[Andrea Galbusera]

Il 12 lug 2017 2:11 PM, "Jussi Kukkonen"  ha
scritto:

Andrea: can you please confirm if this fixes the issue with
meta-raspberrypi (the second patch is just cosmetic)?


I'll give it a spin as soon as I find some spare cycles! BTW, thank you
guys for looking into it!


This should fix mesa-gl and RPi userland conflict by not installing
khrplatform.h in mesa-gl. I decided to do an actual mesa patch instead
of a do_install_append() based on positive comments from upstream.

As a side note: the header is now installed in libegl-mesa-dev which
is not really correct. I'll see about fixing this in a later patch.

Cheers,
  Jussi

The following changes since commit 81498aac9560fbeaeb58eaada32ce80e0ea51628:

  yocto-project-qs: Updated Next Steps list (2017-07-12 00:28:16 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/khr-headers
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/khr-headers

Jussi Kukkonen (2):
  mesa: Avoid installing khrplatfrom.h when not needed
  mesa-gl: Clean recipe

 ...ly-install-khrplatform.h-with-EGL-or-GLES.patch | 52
++
 meta/recipes-graphics/mesa/mesa-gl_17.1.4.bb   |  4 --
 meta/recipes-graphics/mesa/mesa_17.1.4.bb  |  1 +
 3 files changed, 53 insertions(+), 4 deletions(-)
 create mode 100644 meta/recipes-graphics/mesa/files/0001-mapi-Only-install-
khrplatform.h-with-EGL-or-GLES.patch

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

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Wed, Jul 12, 2017 at 7:11 AM, Khem Raj <raj.k...@gmail.com> wrote:

> On Tue, Jul 11, 2017 at 9:56 PM, Andrea Galbusera <giz...@gmail.com>
> wrote:
> > On Wed, Jul 12, 2017 at 12:38 AM, Khem Raj <raj.k...@gmail.com> wrote:
> >>
> >> On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera <giz...@gmail.com>
> >> wrote:
> >> >
> >> >
> >> > Il 11 lug 2017 8:00 PM, "Khem Raj" <raj.k...@gmail.com> ha scritto:
> >> >
> >> > On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
> >> > <jussi.kukko...@intel.com> wrote:
> >> >> On 11 July 2017 at 11:27, Jussi Kukkonen <jussi.kukko...@intel.com>
> >> >> wrote:
> >> >>>
> >> >>> On 11 July 2017 at 10:42, Jussi Kukkonen <jussi.kukko...@intel.com>
> >> >>> wrote:
> >> >>>>>
> >> >>>>> Exception: FileExistsError: [Errno 17] File exists:
> >> >>>>>
> >> >>>>>
> >> >>>>> '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/
> sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
> >> >>>>> ->
> >> >>>>>
> >> >>>>>
> >> >>>>> '/home/gizero/work/smartliving/distro/repo-
> master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-
> linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/
> KHR/khrplatform.h'
> >> >>>>
> >> >>>>
> >> >>>> /usr/include/KHR/khrplatform.h is the egl platform header file,
> >> >>>> provided
> >> >>>> by both mesa and RPI userland. Does mesa end up in your gtk+3
> >> >>>> recipe-sysroot
> >> >>>> somehow?
> >> >>>>
> >> >>>> For clarity: this could be a bug but it is unlikely to be related
> to
> >> >>>> the
> >> >>>> libepoxy change (it does not use or ship the actual header file).
> >> >>>>
> >> >>>
> >> >>>
> >> >>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 --
> >> >>> mesa
> >> >>> accidentally shipped khrplatform.h even when egl was disabled (which
> >> >>> is
> >> >>> what
> >> >>> mesa-gl in oe-core does).
> >> >>>
> >> >>
> >> >> Sorry, I've not had enough  coffee. It was the other way round:
> >> >> khrplatform.h is the platform header that mesa now thinks is needed
> >> >> whether
> >> >> egl is enabled or not -- so they've started installing it in any case
> >> >> from
> >> >> 17.1.4 which means mesa-gl now provides khrplatform.h and thus
> >> >> conflicts
> >> >> with userland.
> >> >>
> >> >> I don't know what the correct fix is yet, just wanted to correct my
> >> >> original
> >> >> wrong info.
> >> >>
> >> >
> >> > Post an update to sync this header for userland package.
> >> >
> >> >
> >> > Will this help solving the gtk+3 issue of mesa-gl and userland now
> both
> >> > providing the same header and causing recipe-sysroot construction to
> >> > fail?
> >>
> >> No it certainly would not. But we can then decide who provides it, in
> >> a easy way.
> >
> >
> > I may be in the need to craft something locally to unbreak building with
> > current master... Could you please shed some light on how this should be
> > done then? Is this a matter of completely removing either mesa-gl or
> > userland from gtk+3 deps or a more selective change to avoid the clash in
> > recipe-sysroot?
>
> Firstly, determine where this file belongs to. If it is part of
> egl/gles then it should go to userland, otherwise it should be
> provided by mesa when using userland for graphics
>

If I understand correctly your point, you mean it is about having the two
upstream agreeing on where the header belongs to and fixing either one or
the other to stop providing it. In the meanwhile, from an oe perspective,
having such a patch in place for any of the two or even removing the file
in an appropriate do_install_append should do the job, right?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Wed, Jul 12, 2017 at 12:38 AM, Khem Raj <raj.k...@gmail.com> wrote:

> On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera <giz...@gmail.com>
> wrote:
> >
> >
> > Il 11 lug 2017 8:00 PM, "Khem Raj" <raj.k...@gmail.com> ha scritto:
> >
> > On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
> > <jussi.kukko...@intel.com> wrote:
> >> On 11 July 2017 at 11:27, Jussi Kukkonen <jussi.kukko...@intel.com>
> wrote:
> >>>
> >>> On 11 July 2017 at 10:42, Jussi Kukkonen <jussi.kukko...@intel.com>
> >>> wrote:
> >>>>>
> >>>>> Exception: FileExistsError: [Errno 17] File exists:
> >>>>>
> >>>>> '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/
> sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
> >>>>> ->
> >>>>>
> >>>>> '/home/gizero/work/smartliving/distro/repo-
> master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-
> linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/
> KHR/khrplatform.h'
> >>>>
> >>>>
> >>>> /usr/include/KHR/khrplatform.h is the egl platform header file,
> provided
> >>>> by both mesa and RPI userland. Does mesa end up in your gtk+3
> >>>> recipe-sysroot
> >>>> somehow?
> >>>>
> >>>> For clarity: this could be a bug but it is unlikely to be related to
> the
> >>>> libepoxy change (it does not use or ship the actual header file).
> >>>>
> >>>
> >>>
> >>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
> >>> accidentally shipped khrplatform.h even when egl was disabled (which is
> >>> what
> >>> mesa-gl in oe-core does).
> >>>
> >>
> >> Sorry, I've not had enough  coffee. It was the other way round:
> >> khrplatform.h is the platform header that mesa now thinks is needed
> >> whether
> >> egl is enabled or not -- so they've started installing it in any case
> from
> >> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
> >> with userland.
> >>
> >> I don't know what the correct fix is yet, just wanted to correct my
> >> original
> >> wrong info.
> >>
> >
> > Post an update to sync this header for userland package.
> >
> >
> > Will this help solving the gtk+3 issue of mesa-gl and userland now both
> > providing the same header and causing recipe-sysroot construction to
> fail?
>
> No it certainly would not. But we can then decide who provides it, in
> a easy way.
>

I may be in the need to craft something locally to unbreak building with
current master... Could you please shed some light on how this should be
done then? Is this a matter of completely removing either mesa-gl or
userland from gtk+3 deps or a more selective change to avoid the clash in
recipe-sysroot?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

Il 11 lug 2017 8:00 PM, "Khem Raj"  ha scritto:

On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
 wrote:
> On 11 July 2017 at 11:27, Jussi Kukkonen  wrote:
>>
>> On 11 July 2017 at 10:42, Jussi Kukkonen 
wrote:

 Exception: FileExistsError: [Errno 17] File exists:
 '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/
sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
 ->
 '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/
cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-
r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>>
>>>
>>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>>> by both mesa and RPI userland. Does mesa end up in your gtk+3
recipe-sysroot
>>> somehow?
>>>
>>> For clarity: this could be a bug but it is unlikely to be related to the
>>> libepoxy change (it does not use or ship the actual header file).
>>>
>>
>>
>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
>> accidentally shipped khrplatform.h even when egl was disabled (which is
what
>> mesa-gl in oe-core does).
>>
>
> Sorry, I've not had enough  coffee. It was the other way round:
> khrplatform.h is the platform header that mesa now thinks is needed
whether
> egl is enabled or not -- so they've started installing it in any case from
> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
> with userland.
>
> I don't know what the correct fix is yet, just wanted to correct my
original
> wrong info.
>

Post an update to sync this header for userland package.


Will this help solving the gtk+3 issue of mesa-gl and userland now both
providing the same header and causing recipe-sysroot construction to fail?


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

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Tue, Jul 11, 2017 at 10:34 AM, Jussi Kukkonen 
wrote:

> On 11 July 2017 at 11:27, Jussi Kukkonen  wrote:
>
>> On 11 July 2017 at 10:42, Jussi Kukkonen 
>> wrote:
>>>
>>> Exception: FileExistsError: [Errno 17] File exists:
 '/home/gizero/work/smartliving/distro/repo-master/build-poky
 /tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
 -> '/home/gizero/work/smartliving/distro/repo-master/build-poky
 /tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.2
 2.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'

>>>
>>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>>> by both mesa and RPI userland. Does mesa end up in your gtk+3
>>> recipe-sysroot somehow?
>>>
>>> For clarity: this could be a bug but it is unlikely to be related to the
>>> libepoxy change (it does not use or ship the actual header file).
>>>
>>>
>>
>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
>> accidentally shipped khrplatform.h even when egl was disabled (which is
>> what mesa-gl in oe-core does).
>>
>>
> Sorry, I've not had enough  coffee. It was the other way round:
> khrplatform.h is the platform header that mesa now thinks is needed whether
> egl is enabled or not -- so they've started installing it in any case from
> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
> with userland.
>
> I don't know what the correct fix is yet, just wanted to correct my
> original wrong info.
>

Ok, got it That was also my initial interpretation of mentioned commit
message which states:

mesa: Upgrade to 17.1.4 release

This includes following upstream bug fixes:

Bug 77240 - khrplatform.h not installed if EGL is disabled
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Tue, Jul 11, 2017 at 10:27 AM, Jussi Kukkonen 
wrote:

> On 11 July 2017 at 10:42, Jussi Kukkonen  wrote:
>>
>> Exception: FileExistsError: [Errno 17] File exists:
>>> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>>> /tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
>>> -> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>>> /tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.2
>>> 2.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>>
>>
>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>> by both mesa and RPI userland. Does mesa end up in your gtk+3
>> recipe-sysroot somehow?
>>
>> For clarity: this could be a bug but it is unlikely to be related to the
>> libepoxy change (it does not use or ship the actual header file).
>>
>>
>
> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
> accidentally shipped khrplatform.h even when egl was disabled (which is
> what mesa-gl in oe-core does).
>
> Make sure you have oe-core commit f0762f5bad3 (poky: 773d10873).
>

Yes I have it, and the cleansstate mentioned above makes me think it got
used as expected. Indeed the commit you mention is part of the bunch of
commits after pulling which I got my builds broken... I'm confused! Any
idea how to figure out which recipe get considered first in gtk+3's
do_prepare_recipe_sysroot and effectively deliver khrplatform.h to the
recipe-sysroot?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Tue, Jul 11, 2017 at 10:06 AM, Jussi Kukkonen <jussi.kukko...@intel.com>
wrote:

> On 10 July 2017 at 17:47, Andrea Galbusera <giz...@gmail.com> wrote:
>
>> During bisection the failing task changed from do_prepare_recipe_sysroot
>> to do_compile with the log below. I have no idea if these things do relate
>> themselves, but if not, I was not able to figure it out while bisecting.
>>
>> | In file included from /home/gizero/work/smartliving/
>> distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4
>> -poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/incl
>> ude/epoxy/egl.h:46:0,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.h:32,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.c:24:
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c: In function
>> 'gdk_wayland_gl_context_realize':
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c:179:43:
>> error: expected expression before 'EGLContext'
>> |  : EGL_NO_CONTEXT,
>> |^
>>
>
> Your bisect seems valid: gtk+3 uses a define that comes from epoxy and was
> changed in the update. The new define uses a EGL_CAST() macro that was
> added to eglplatform.h at the same time. mesa has updated their
> eglplatform.h so it all seems to work, but userland does not seem to have
> this macro?
>
> There's probably more to the story (since the error is not about implicit
> EGL_CAST() as one would expect). My first suggestion would be that userland
> eglplatform.h is updated to match current Khronos registry or at least to
> include the EGL_CAST definition.
>

I looked at the userland upstream repo and they don't seem to have updates
on their eglplatform.h since 2015...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Tue, Jul 11, 2017 at 9:42 AM, Jussi Kukkonen <jussi.kukko...@intel.com>
wrote:

> On 10 July 2017 at 17:47, Andrea Galbusera <giz...@gmail.com> wrote:
>
>> On Tue, Jun 27, 2017 at 3:16 PM, Jussi Kukkonen <jussi.kukko...@intel.com
>> > wrote:
>>
>>> Imports the current EGL API registry from Khronos.
>>>
>>> Makes EGL support optional: this is reflected in the recipe but
>>> egl is enabled by default as before.
>>>
>>> Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
>>> ---
>>>  .../libepoxy/{libepoxy_1.4.2.bb => libepoxy_1.4.3.bb}| 9
>>> +
>>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>>  rename meta/recipes-graphics/libepoxy/{libepoxy_1.4.2.bb =>
>>> libepoxy_1.4.3.bb} (70%)
>>>
>>> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>>> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> similarity index 70%
>>> rename from meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>>> rename to meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> index e69e828..c8b398f 100644
>>> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>>> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> @@ -6,15 +6,16 @@ LICENSE = "MIT"
>>>  LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d4
>>> 01e07bd9ee8b6b58cf464b"
>>>
>>>  SRC_URI = "https://github.com/anholt/${BPN}/releases/download/${PV}/${
>>> BP}.tar.xz"
>>> -SRC_URI[md5sum] = "632fcfd7ae9d21f5a634326d753a89c4"
>>> -SRC_URI[sha256sum] = "bea6fdec3d10939954495da898d87
>>> 2ee836b75c35699074cbf02a64fcb80d5b3"
>>> +SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
>>> +SRC_URI[sha256sum] = "0b808a06c9685a62fca34b680abb8
>>> bc7fb2fda074478e329b063c1f872b826f6"
>>>  UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
>>>
>>>  inherit autotools pkgconfig distro_features_check
>>>
>>>  REQUIRED_DISTRO_FEATURES = "opengl"
>>>
>>> -DEPENDS = "util-macros virtual/egl"
>>> +DEPENDS = "util-macros"
>>>
>>> +PACKAGECONFIG[egl] = "--enable-egl, --disable-egl, virtual/egl"
>>>  PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
>>> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>>> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}
>>> egl"
>>> --
>>> 2.1.4
>>>
>>
>> Beside the issue with recent patch to mesa, also this one seems to have
>> caused nasty effects on raspberrypi builds... I got to it after bisecting
>> poky from 854c8c2 that failed with:
>>
>> ERROR: gtk+3-3.22.16-r0 do_prepare_recipe_sysroot: Error executing a
>> python function in exec_python_func() autogenerated:
>>
>> The stack trace of python calls that resulted in this exception/failure
>> was:
>> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>>  0001:
>>  *** 0002:extend_recipe_sysroot(d)
>>  0003:
>> File: '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /conf/../../layers/poky/meta/classes/staging.bbclass', lineno: 510,
>> function: extend_recipe_sysroot
>>  0506:dest = newmanifest[l]
>>  0507:if l.endswith("/"):
>>  0508:staging_copydir(l, targetdir, dest,
>> seendirs)
>>  0509:continue
>>  *** 0510:staging_copyfile(l, targetdir, dest,
>> postinsts, seendirs)
>>  0511:
>>  0512:for f in fixme:
>>  0513:if f == '':
>>  0514:staging_processfixme(fixme[f], recipesysroot,
>> recipesysroot, recipesysrootnative, d)
>> File: '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /conf/../../layers/poky/meta/classes/staging.bbclass', lineno: 151,
>> function: staging_copyfile
>>  0147:os.symlink(linkto, dest)
>>  0148:#bb.warn(c)
>>  0149:else:
>>  0150:try:
>>  *** 0151:os.link(c, dest)
>>  0152:except OSError as err:
>>  0153:if err.errno == errno.EXDEV:
>>  0154:bb.utils.copyfile(c, dest)
>>  0155:else:
>> Exception: FileExistsError: [Errno 17] File

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Andrea Galbusera]

On Tue, Jun 27, 2017 at 3:16 PM, Jussi Kukkonen 
wrote:

> Imports the current EGL API registry from Khronos.
>
> Makes EGL support optional: this is reflected in the recipe but
> egl is enabled by default as before.
>
> Signed-off-by: Jussi Kukkonen 
> ---
>  .../libepoxy/{libepoxy_1.4.2.bb => libepoxy_1.4.3.bb}| 9
> +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>  rename meta/recipes-graphics/libepoxy/{libepoxy_1.4.2.bb =>
> libepoxy_1.4.3.bb} (70%)
>
> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> similarity index 70%
> rename from meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
> rename to meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> index e69e828..c8b398f 100644
> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> @@ -6,15 +6,16 @@ LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d401e07bd9ee8b6b58cf464b"
>
>  SRC_URI = "https://github.com/anholt/${BPN}/releases/download/${PV}/${
> BP}.tar.xz"
> -SRC_URI[md5sum] = "632fcfd7ae9d21f5a634326d753a89c4"
> -SRC_URI[sha256sum] = "bea6fdec3d10939954495da898d87
> 2ee836b75c35699074cbf02a64fcb80d5b3"
> +SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
> +SRC_URI[sha256sum] = "0b808a06c9685a62fca34b680abb8
> bc7fb2fda074478e329b063c1f872b826f6"
>  UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
>
>  inherit autotools pkgconfig distro_features_check
>
>  REQUIRED_DISTRO_FEATURES = "opengl"
>
> -DEPENDS = "util-macros virtual/egl"
> +DEPENDS = "util-macros"
>
> +PACKAGECONFIG[egl] = "--enable-egl, --disable-egl, virtual/egl"
>  PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
> --
> 2.1.4
>

Beside the issue with recent patch to mesa, also this one seems to have
caused nasty effects on raspberrypi builds... I got to it after bisecting
poky from 854c8c2 that failed with:

ERROR: gtk+3-3.22.16-r0 do_prepare_recipe_sysroot: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '/home/gizero/work/smartliving/distro/repo-
master/build-poky/conf/../../layers/poky/meta/classes/staging.bbclass',
lineno: 510, function: extend_recipe_sysroot
 0506:dest = newmanifest[l]
 0507:if l.endswith("/"):
 0508:staging_copydir(l, targetdir, dest,
seendirs)
 0509:continue
 *** 0510:staging_copyfile(l, targetdir, dest,
postinsts, seendirs)
 0511:
 0512:for f in fixme:
 0513:if f == '':
 0514:staging_processfixme(fixme[f], recipesysroot,
recipesysroot, recipesysrootnative, d)
File: '/home/gizero/work/smartliving/distro/repo-
master/build-poky/conf/../../layers/poky/meta/classes/staging.bbclass',
lineno: 151, function: staging_copyfile
 0147:os.symlink(linkto, dest)
 0148:#bb.warn(c)
 0149:else:
 0150:try:
 *** 0151:os.link(c, dest)
 0152:except OSError as err:
 0153:if err.errno == errno.EXDEV:
 0154:bb.utils.copyfile(c, dest)
 0155:else:
Exception: FileExistsError: [Errno 17] File exists: '/home/gizero/work/
smartliving/distro/repo-master/build-poky/tmp/sysroots-components/
raspberrypi3/userland/usr/include/KHR/khrplatform.h' -> '/home/gizero/work/
smartliving/distro/repo-master/build-poky/tmp/work/
cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-
r0/recipe-sysroot/usr/include/KHR/khrplatform.h'

ERROR: gtk+3-3.22.16-r0 do_prepare_recipe_sysroot: Function failed:
extend_recipe_sysroot
ERROR: Logfile of failure stored in: /home/gizero/work/smartliving/
distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-
vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/temp/log.do_
prepare_recipe_sysroot.31798
ERROR: Task (/home/gizero/work/smartliving/distro/repo-
master/build-poky/conf/../../layers/poky/meta/recipes-
gnome/gtk+/gtk+3_3.22.16.bb:do_prepare_recipe_sysroot) failed with exit
code '1'

During bisection the failing task changed from do_prepare_recipe_sysroot to
do_compile with the log below. I have no idea if these things do relate
themselves, but if not, I was not able to figure it out while bisecting.

| In file included from /home/gizero/work/smartliving/
distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-
vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/
usr/include/epoxy/egl.h:46:0,
|  from ../../../gtk+-3.22.16/gdk/

Re: [OE-core] [PATCH] mesa: Split --with-platforms from egl PACKAGECONFIG

[Andrea Galbusera]

On Mon, Jul 10, 2017 at 3:32 PM, Otavio Salvador  wrote:

> On Mon, Jul 10, 2017 at 8:54 AM, Jussi Kukkonen
>  wrote:
> > Mesa platforms no longer depend directly on egl. Current
> > implementation breaks without egl with x11 (which can happen with
> > mesa-gl).
> >
> > Separate the platform selection. Make drm platform depend on gbm
> > PACKAGECONFIG by default.
> >
> > Signed-off-by: Jussi Kukkonen 
> > ---
>
> I tested it here and seems good. Ross please put this on MUT so we can
> merge it soon.
>

I also tested it and solves the issue seen with meta-raspberrypi builds.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 1/2] mesa: Avoid platform probing when building without EGL

[Andrea Galbusera]

Hi!

On Mon, Jul 3, 2017 at 10:02 PM, Otavio Salvador 
wrote:

> The 17.1.2 release has changed the platform setting and when not
> explicitly disabled it assumes x11 support.
>
> Fixes:
>
> | checking for x11-xcb xcb xcb-dri2 >= 1.8 xcb-xfixes... no
> | configure: error: Package requirements (x11-xcb xcb xcb-dri2 >= 1.8
> xcb-xfixes) were not met:
> |
> | No package 'x11-xcb' found
> | No package 'xcb' found
> | No package 'xcb-dri2' found
> | No package 'xcb-xfixes' found
> |
> | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> | installed software in a non-standard prefix.
> |
> | Alternatively, you may set the environment variables XCB_DRI2_CFLAGS
> | and XCB_DRI2_LIBS to avoid the need to call pkg-config.
> | See the pkg-config man page for more details.
>
> The issue has been exposed by meta-freescale BSP. Fix tested with
> imx6qsabresd machine.
>
> Signed-off-by: Otavio Salvador 
> ---
>
> Changes in v2:
> - new patch
>
>  meta/recipes-graphics/mesa/mesa.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index 41747cffc8..a12ab7ab5b 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -49,7 +49,7 @@ PACKAGECONFIG[gles] = "--enable-gles1 --enable-gles2,
> --disable-gles1 --disable-
>  EGL_PLATFORMS  = "drm"
>  EGL_PLATFORMS .="${@bb.utils.contains('PACKAGECONFIG', 'x11', ',x11',
> '', d)}"
>  EGL_PLATFORMS .="${@bb.utils.contains('PACKAGECONFIG', 'wayland',
> ',wayland', '', d)}"
> -PACKAGECONFIG[egl] = "--enable-egl --with-platforms=${EGL_PLATFORMS},
> --disable-egl"
> +PACKAGECONFIG[egl] = "--enable-egl --with-platforms=${EGL_PLATFORMS},
> --disable-egl --with-platforms=''"
>
>  PACKAGECONFIG[etnaviv] = ""
>  PACKAGECONFIG[imx] = ""
> --
> 2.13.2
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


After merging this patch (as per current poky master), builds for
MACHINE=raspberrypi3 with meta-raspberrypi fail complaining like this:

| checking for x11 xext xdamage >= 1.1 xfixes x11-xcb xcb xcb-glx >= 1.8.1
xcb-dri2 >= 1.8 xxf86vm... yes
| checking for wayland-scanner... no
| configure: error: Building without the x11 platform as GLX is enabled, is
not supported
| NOTE: The following config.log files may provide further information.
| NOTE:
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_17.1.4-r0/build/config.log
| ERROR: configure failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_17.
1.4-r0/temp/log.do_configure.11176)

I know very little about graphical stacks since I use these systems mostly
headless. Can anyone have a look into it? BTW, without this only commit,
the build runs to the end with no other errors.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] volatile-binds and DNS

[Andrea Galbusera]

On Thu, May 18, 2017 at 9:16 AM, Kristian Amlie 
wrote:

> We've discovered that one of the recent commits to poky has broken DNS
> resolution in our image. The commit in questions is this one:
>
> ---
> commit fcd48092d7bcab0cad2606e65332da62420935ad
> Author: Joe Slater 
> Date:   Fri Mar 31 03:06:33 2017
>
> volatile-binds: correct some errors reported by systemd
>
> systemd-tmpfiles-setup will fail at boot, so we suppress
> the default versions of etc.conf and home.conf.
>
> We also make sure that /var/{cache,spool} and /srv are writeable
> if they exist.
> ...
> ---
>
> The problem is that this suppresses the creation of a /etc/resolv.conf
> file, and without that DNS does not work.
>
> The file is a symlink to the resolv.conf that systemd provides in
> /run/systemd/resolve/resolv.conf, so it could potentially be
> prepopulated, but I admit I don't fully understand how this fits together.
>
> Any advice?
>

There's a bug open on this [1]. My workaround as for now is to apply [2],
but I'm not completely aware of the issue that suggested the original
commit you mention, hence there might be a better approach to fix this...

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11331
[2]
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/136074.html



>
> --
> Kristian
> --
> ___
> 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] [Openembedded-architecture] [oe] OpenEmbedded 2017 General Meeting

[Andrea Galbusera]

On Mon, May 1, 2017 at 1:59 PM, Martin Jansa  wrote:

> I had to change the password on the login, but then it worked for me.
>
> I've added Andrea and Andrei to the list.
>

Thanks!


>
> On Mon, May 1, 2017 at 1:46 PM, Philip Balister 
> wrote:
>
>> On 05/01/2017 07:42 AM, Richard Purdie wrote:
>> > On Mon, 2017-05-01 at 13:07 +0200, Nicolas Dechesne wrote:
>> >> well, it's the same for me. In the 'view source' page, i can see
>> >> this:
>> >>
>> >> ==
>> >> You do not have permission to edit this page, for the following
>> >> reason:
>> >> The action you have requested is limited to users in the group:
>> >> Administrators.
>> >
>> > Right, it is totally broken.
>> >
>> > Someone has messed up the group access permissions, likely related to
>> > spam protection. Right now it appears only the admins can change
>> > anything. I could try and fix it but I should probably understand who
>> > did what and why to cause this first.
>> >
>> > Who has changed the group permissions recently?
>>
>> I'll check with Bill Traynor.
>>
>> Philip
>>
>> >
>> > Cheers,
>> >
>> > Richard
>> > ___
>> > Openembedded-architecture mailing list
>> > openembedded-architect...@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-
>> architecture
>> >
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] OpenEmbedded 2017 General Meeting

[Andrea Galbusera]

On Mon, May 1, 2017 at 12:02 PM, Andrei Gherzan  wrote:

> On Wed, Apr 19, 2017 at 9:48 PM, Sean Hudson 
> wrote:
> > The board would like to hold a general meeting with all members.  Under
> > the new by-laws of the OpenEmbedded organization, we can meet
> > electronically.  This will also fulfill the requirement for an annual,
> > general meeting.
> >
> > Planned Date/Time:
> > Wednesday, May 3rd, at 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00)
> >
> > Wiki page with full details, including teleconference information here:
> > http://www.openembedded.org/wiki/2017_General_Meeting
>
> It seems like there is not Edit button for me to add my username to
> the attendee list.


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

[OE-core] [PATCH] Partially revert "volatile-binds: correct some errors reported by systemd"

[Andrea Galbusera]

Suppressing default version of etc.conf for systemd-tmpfiles-setup prevents at
least the name resolver from working as expected when using systemd-resolved.
The missing /etc/resolv.conf symlink breaks application relying on this for
name resolution (tested with ping from busybox).

This patch brings default etc.conf from systemd recipe back, solving the
broken name resolution issue.

[YOCTO #11331]

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 meta/recipes-core/volatile-binds/volatile-binds.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb 
b/meta/recipes-core/volatile-binds/volatile-binds.bb
index a6e3254..943e6ba 100644
--- a/meta/recipes-core/volatile-binds/volatile-binds.bb
+++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
@@ -74,7 +74,6 @@ do_install () {
 # Suppress attempts to process some tmpfiles that are not temporary.
 #
 install -d ${D}${sysconfdir}/tmpfiles.d ${D}/var/cache
-ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/etc.conf
 ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/home.conf
 }
 do_install[dirs] = "${WORKDIR}"
-- 
2.7.4

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

Re: [OE-core] Fwd: Recipe [patch] modification to generate a static library instead of shared library

[Andrea Galbusera]

Hi,

On Thu, Apr 6, 2017 at 10:11 PM, Ravi chandra reddy 
wrote:

> Hi,
> I am trying to generate LibIIO [open source by Analog Devices],
> however there is dependancy on Libxml2.
>

For libiio there is a recipe in meta-openembedded [1]. Are you using that
one?

[1] http://layers.openembedded.org/layerindex/recipe/57509/


> problem with Libxml2, it is dependant on *python*-lib, libdl, libz,
> libzma, libm
>
> for some reason with Yocto built Libxml2.so, i am encountering "undefined
> references error", which i am unable to solve [inspite of linking possible
> dependant libraries],
>
> if i get could the Libxml2.a, it packages all "REQUIRED ELEMENTS", so i
> assume, there WONT be any error in linking Libxml2 in Libiio.
>
> ==in short=
> Libiio ---linking---> Libxml2*.so* [yocto based] ---errors-> undefined
> referneces to .
>
> ==in short=
> Libiio ---linking---> Libxml2.a [yocto based] --> SHOULD solve and install
> libiio
>
> for me to generate Libxml2.a, i need to make/ask yocto build LIbxml2.a for
> me. i tried putting libxml2-staticdev  in the local.conf file and it gives
> me build error.
>
> all i want is Libxml2.a which is to be used by Libiio.so/Libiio.a to be
> used by an application [called in user space of AARCH linux]
>
>
> Thanks
> RC
>
> On Thu, Apr 6, 2017 at 3:17 PM, Matthew McClintock  > wrote:
>
>> On Thu, Apr 6, 2017 at 9:20 AM, Ravi chandra reddy 
>> wrote:
>> > Hi,
>> >  Is there any hidden pointer within these static dev packages. i
>> > expected the library to be .a format. what can i understand from these
>> > static dev packages, plz let me know.
>>
>> Can you expand on what you're trying to accomplish? Are you trying to
>> build a static binary? I don't think you actually are trying to
>> install libxml2.a on the running image are you? Maybe you really want
>> an SDK with a sysroot populated with static libraries so you can link
>> against them?
>>
>> -M
>>
>
>
> --
> ___
> 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] oe-publish-sdk: add pyshtables.py to .gitignore

[Andrea Galbusera]

pyshtables.py should be ignored by git as it is generated. If kept in
the repo, causes subsequent runs of sdk-update to fail.

[ YOCTO #10963 ]

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
Changes in v2:
- don't hardcode pyshtables.py path in .gitconfig
---
 scripts/oe-publish-sdk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/oe-publish-sdk b/scripts/oe-publish-sdk
index 4fe8974..9f7963c 100755
--- a/scripts/oe-publish-sdk
+++ b/scripts/oe-publish-sdk
@@ -114,9 +114,9 @@ def publish(args):
 
 # Setting up the git repo
 if not is_remote:
-cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; mv .git/hooks/post-update.sample .git/hooks/post-update; echo 
"*.pyc\n*.pyo" > .gitignore; fi; git add -A .; git config user.email 
"o...@oe.oe" && git config user.name "OE" && git commit -q -m "init repo" || 
true; git update-server-info' % (destination, destination)
+cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; mv .git/hooks/post-update.sample .git/hooks/post-update; echo 
"*.pyc\n*.pyo\npyshtables.py" > .gitignore; fi; git add -A .; git config 
user.email "o...@oe.oe" && git config user.name "OE" && git commit -q -m "init 
repo" || true; git update-server-info' % (destination, destination)
 else:
-cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; mv .git/hooks/post-update.sample 
.git/hooks/post-update; echo '*.pyc\n*.pyo' > .gitignore; fi; git add -A .; git 
config user.email 'o...@oe.oe' && git config user.name 'OE' && git commit -q -m 
\"init repo\" || true; git update-server-info'" % (host, destdir, destdir)
+cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; mv .git/hooks/post-update.sample 
.git/hooks/post-update; echo '*.pyc\n*.pyo\npyshtables.py' > .gitignore; fi; 
git add -A .; git config user.email 'o...@oe.oe' && git config user.name 'OE' 
&& git commit -q -m \"init repo\" || true; git update-server-info'" % (host, 
destdir, destdir)
 ret = subprocess.call(cmd, shell=True)
 if ret == 0:
 logger.info('SDK published successfully')
-- 
2.7.4

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

[OE-core] [PATCH] oe-publish-sdk: add pyshtables.py to .gitignore

[Andrea Galbusera]

poky/bitbake/lib/bb/pysh/pyshtables.py should be ignored by git as it is
generated. If kept in the repo, causes subsequent runs of sdk-update to fail.

[ YOCTO #10963 ]

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 scripts/oe-publish-sdk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/oe-publish-sdk b/scripts/oe-publish-sdk
index 4fe8974..8979405 100755
--- a/scripts/oe-publish-sdk
+++ b/scripts/oe-publish-sdk
@@ -114,9 +114,9 @@ def publish(args):
 
 # Setting up the git repo
 if not is_remote:
-cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; mv .git/hooks/post-update.sample .git/hooks/post-update; echo 
"*.pyc\n*.pyo" > .gitignore; fi; git add -A .; git config user.email 
"o...@oe.oe" && git config user.name "OE" && git commit -q -m "init repo" || 
true; git update-server-info' % (destination, destination)
+cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; mv .git/hooks/post-update.sample .git/hooks/post-update; echo 
"*.pyc\n*.pyo\npoky/bitbake/lib/bb/pysh/pyshtables.py" > .gitignore; fi; git 
add -A .; git config user.email "o...@oe.oe" && git config user.name "OE" && 
git commit -q -m "init repo" || true; git update-server-info' % (destination, 
destination)
 else:
-cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; mv .git/hooks/post-update.sample 
.git/hooks/post-update; echo '*.pyc\n*.pyo' > .gitignore; fi; git add -A .; git 
config user.email 'o...@oe.oe' && git config user.name 'OE' && git commit -q -m 
\"init repo\" || true; git update-server-info'" % (host, destdir, destdir)
+cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; mv .git/hooks/post-update.sample 
.git/hooks/post-update; echo 
'*.pyc\n*.pyo\npoky/bitbake/lib/bb/pysh/pyshtables.py' > .gitignore; fi; git 
add -A .; git config user.email 'o...@oe.oe' && git config user.name 'OE' && 
git commit -q -m \"init repo\" || true; git update-server-info'" % (host, 
destdir, destdir)
 ret = subprocess.call(cmd, shell=True)
 if ret == 0:
 logger.info('SDK published successfully')
-- 
2.7.4

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