[OE-core] [PATCH] nativesdk-bison: Add to nativesdk-packagegroup-sdk-host and set BISON_PKGDATADIR

[zhe.he]

From: He Zhe 

bison is needed when building kernel. Add it to nativesdk-packagegroup-sdk-host
and set BISON_PKGDATADIR for bison to use its components.

Signed-off-by: He Zhe 
---
 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
 meta/recipes-devtools/bison/bison_3.0.4.bb | 4 
 2 files changed, 5 insertions(+)

diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index e2f6169..448c2f6 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -25,6 +25,7 @@ RDEPENDS_${PN} = "\
 nativesdk-cmake \
 ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
'', d)} \
 nativesdk-sdk-provides-dummy \
+nativesdk-bison \
 "
 
 RDEPENDS_${PN}_darwin = "\
diff --git a/meta/recipes-devtools/bison/bison_3.0.4.bb 
b/meta/recipes-devtools/bison/bison_3.0.4.bb
index cc155f0..f1b05da 100644
--- a/meta/recipes-devtools/bison/bison_3.0.4.bb
+++ b/meta/recipes-devtools/bison/bison_3.0.4.bb
@@ -36,4 +36,8 @@ do_install_append_class-native() {
create_wrapper ${D}/${bindir}/bison \
BISON_PKGDATADIR=${STAGING_DATADIR_NATIVE}/bison
 }
+do_install_append_class-nativesdk() {
+   create_wrapper ${D}/${bindir}/bison \
+   BISON_PKGDATADIR=${datadir}/bison
+}
 BBCLASSEXTEND = "native nativesdk"
-- 
2.7.4

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

Re: [OE-core] [PATCH] wic:mkefidisk:add use-uuid for all partitions

[Lu.Jiang]

Hi Richard,
Ping for this patch.

Thanks
Jiang Lu

在 2018年09月25日 10:31, Lu.Jiang 写道:

Hi Richard,
The patch is revied by Tom, can you help merge this patch?

Thanks
Jiang Lu

在 2018年09月07日 19:56, Tom Rini 写道:

On Fri, Sep 07, 2018 at 11:32:11AM +0800, Jiang Lu wrote:


Add use-uuid for all partitions on mkefidisk.wks.

Signed-off-by: Jiang Lu 

Reviewed-by: Tom Rini 





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

Re: [OE-core] [yocto] layers.openembedded.org upgraded

[Randy MacLeod]

On 09/27/2018 07:33 PM, Paul Eggleton wrote:

Hi Randy

On Friday, 28 September 2018 11:22:29 AM NZST Randy MacLeod wrote:

On 09/27/2018 05:28 PM, Nicolas Dechesne wrote:

On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton  wrote:

I'm very happy to announce that we've finally been able to upgrade the layer
index at http://layers.openembedded.org to the latest revision on master,
incorporating quite a bit of work that's been going on for the past few
months. Improvements now visible:

Nice new features, thanks!

The "Branch:" and "Filter layers" selection menus don't work
for me when using Firefox 62.0 (64-bit) on Ubuntu-18.04.

Google Chrome Version 69.0.3497.100 (Official Build) (64-bit)
works fine.

Hmm, I do my development with Firefox and I just checked - with Firefox
62.0 (64-bit) here on Fedora 28 both work. Do you perhaps have an add-on
enabled that might prevent these from working? I believe they both rely on
javascript (the filter dropdown definitely does).


Does anyone else see this problem?
I've also asked on IRC.

I did have Firefox Lightbeam (disabled) and Quiick Java but I removed 
them both,

re-stared FF and still no joy/menus.


Looking at:
Menu->Web Developer -> Browser Console ( Control+Shift+J )
I see:

Error: Syntax error, unrecognized expression: # jquery-3.3.1.js:1541:8 

Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:1541:8 
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2193:4 
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2620:20 Sizzle 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:845:9 find 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:2873:4 
jQuery.fn.init 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:2983:14 jQuery 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:139:10 
getParent https://layers.openembedded.org/static/js/bootstrap.js:754:27 
clearMenus/< 
https://layers.openembedded.org/static/js/bootstrap.js:741:7 each 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:354:10 each 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:189:10 
clearMenus https://layers.openembedded.org/static/js/bootstrap.js:740:5 
dispatch 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:5182:16 
add/elemData.handle 
https://layers.openembedded.org/static/js/jquery-3.3.1.js:4991:6


Does that help at all?

../Randy





Cheers,
Paul



--
# Randy MacLeod
# Wind River Linux

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

Re: [OE-core] [PATCH] layer.conf: Drop sumo from LAYERSERIES_CORENAMES

[Khem Raj]

will it result in hard error ?
On Thu, Sep 27, 2018 at 3:41 PM Richard Purdie
 wrote:
>
> Prepare for release and drop sumo for the compatible list of layer names.
> This will mean other layers need updating to continue to indicate 
> compatibility
> with master but that is intentional at this part of the release cycle, we want
> layers to indicate compatibility and show they're up to date.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/layer.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index 0728c51e5fd..6221a057ce6 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -7,7 +7,7 @@ BBFILE_COLLECTIONS += "core"
>  BBFILE_PATTERN_core = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_core = "5"
>
> -LAYERSERIES_CORENAMES = "sumo thud"
> +LAYERSERIES_CORENAMES = "thud"
>
>  # This should only be incremented on significant changes that will
>  # cause compatibility issues with other layers
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] layers.openembedded.org upgraded

[Paul Eggleton]

Hi Randy

On Friday, 28 September 2018 11:22:29 AM NZST Randy MacLeod wrote:
> On 09/27/2018 05:28 PM, Nicolas Dechesne wrote:
> > On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton  
> > wrote:
> >> I'm very happy to announce that we've finally been able to upgrade the 
> >> layer
> >> index at http://layers.openembedded.org to the latest revision on master,
> >> incorporating quite a bit of work that's been going on for the past few
> >> months. Improvements now visible:
> 
> Nice new features, thanks!
> 
> The "Branch:" and "Filter layers" selection menus don't work
> for me when using Firefox 62.0 (64-bit) on Ubuntu-18.04.
> 
> Google Chrome Version 69.0.3497.100 (Official Build) (64-bit)
> works fine.

Hmm, I do my development with Firefox and I just checked - with Firefox
62.0 (64-bit) here on Fedora 28 both work. Do you perhaps have an add-on
enabled that might prevent these from working? I believe they both rely on
javascript (the filter dropdown definitely does).

Cheers,
Paul

-- 
Paul Eggleton
Intel Open Source Technology Centre


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

Re: [OE-core] [yocto] layers.openembedded.org upgraded

[Randy MacLeod]

On 09/27/2018 05:28 PM, Nicolas Dechesne wrote:

On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton  wrote:


Hi all, >>
I'm very happy to announce that we've finally been able to upgrade the layer
index at http://layers.openembedded.org to the latest revision on master,
incorporating quite a bit of work that's been going on for the past few
months. Improvements now visible:


Nice new features, thanks!

The "Branch:" and "Filter layers" selection menus don't work
for me when using Firefox 62.0 (64-bit) on Ubuntu-18.04.

Google Chrome Version 69.0.3497.100 (Official Build) (64-bit)
works fine.

../Randy




* Patch tracking - each recipe detail page now lists any patches being applied
by the recipe along with upstream status for each - see attached screenshot.
You can click through to view/download the actual patch, and any URLs in the
supplemental status text are also made into clickable links.

* Source tracking - remote entries in SRC_URI are now listed on the recipe
detail page and made into clickable links where possible - see attached
screenshot

* Link to inc files - there is now a link in the recipe detail page to any inc
files that a recipe includes as long as they are in the same directory, as a
shortcut to see the rest of the definitions for the recipe.

* Recipe list CSV export - there is now an "Export CSV" button at the top of
the recipe list on the layer detail page. This currently includes the recipe
name and version - we could look at extending this, but note that the REST API
provides access to all of the information programmatically and may be better
suited for many applications that need this data.

* Site-wide notice support - admins can now add notifications to appear at the
top of the page across the entire site. This is useful in the case where there
is some problem with the update process or maintenance is going on as happens
from time to time.

* Bootstrap 3 - the UI has been updated to use Bootstrap 3 from version 2 that
we were using previously. This has made a fairly minor difference to the UI
(padding/spacing/fonts have changed a little) but has allowed us to tidy up a
few things in the code.

* The "Base" layer type is no longer selectable for layer submissions. I
noticed people sometimes selected this erroneously; it's only applicable for
openembedded-core and meta-oe basically so that they show up at the top of the
layer list. Only admins can now select this type for a layer.

* Numerous other bugfixes, robustness improvements and code cleanups.

Thanks very much to everyone who has contributed to the layer index code up to
now (and to BitBake / tinfoil, which we rely upon to extract the information
from the metadata), but I'd like to give particular thanks to Michael
Halstead, Yi Zhao, Konrad Scherer, Robert Yang and Aníbal Limón for making
this upgrade possible.


Paul, and everyone above, many thanks for your contributions to the
Layer Index which is definitely a great tool for our community! It
encourages and simplifies reuse and sharing of all recipes! The update
looks really good, and as Andreas says, the top #3 features will make
a big difference.




Also integrated were the Recipe Reporting System (RRS) which powers
http://recipes.yoctoproject.org and other distro comparison support, but these
will take a bit more time to properly enable so I'll send out a separate email
with further details when they are ready.

As always, please let me know if you have any comments or notice any issues.
(I've already seen a few minor problems in the update logs so I'll be looking
into those.)

Cheers,
Paul

--
Paul Eggleton
Intel Open Source Technology Centre--
___
yocto mailing list
yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] layer.conf: Drop sumo from LAYERSERIES_CORENAMES

[Richard Purdie]

Prepare for release and drop sumo for the compatible list of layer names.
This will mean other layers need updating to continue to indicate compatibility
with master but that is intentional at this part of the release cycle, we want
layers to indicate compatibility and show they're up to date.

Signed-off-by: Richard Purdie 
---
 meta/conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 0728c51e5fd..6221a057ce6 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -7,7 +7,7 @@ BBFILE_COLLECTIONS += "core"
 BBFILE_PATTERN_core = "^${LAYERDIR}/"
 BBFILE_PRIORITY_core = "5"
 
-LAYERSERIES_CORENAMES = "sumo thud"
+LAYERSERIES_CORENAMES = "thud"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers
-- 
2.17.1

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

Re: [OE-core] [yocto] layers.openembedded.org upgraded

[Nicolas Dechesne]

On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton  wrote:
>
> Hi all,
>
> I'm very happy to announce that we've finally been able to upgrade the layer
> index at http://layers.openembedded.org to the latest revision on master,
> incorporating quite a bit of work that's been going on for the past few
> months. Improvements now visible:
>
> * Patch tracking - each recipe detail page now lists any patches being applied
> by the recipe along with upstream status for each - see attached screenshot.
> You can click through to view/download the actual patch, and any URLs in the
> supplemental status text are also made into clickable links.
>
> * Source tracking - remote entries in SRC_URI are now listed on the recipe
> detail page and made into clickable links where possible - see attached
> screenshot
>
> * Link to inc files - there is now a link in the recipe detail page to any inc
> files that a recipe includes as long as they are in the same directory, as a
> shortcut to see the rest of the definitions for the recipe.
>
> * Recipe list CSV export - there is now an "Export CSV" button at the top of
> the recipe list on the layer detail page. This currently includes the recipe
> name and version - we could look at extending this, but note that the REST API
> provides access to all of the information programmatically and may be better
> suited for many applications that need this data.
>
> * Site-wide notice support - admins can now add notifications to appear at the
> top of the page across the entire site. This is useful in the case where there
> is some problem with the update process or maintenance is going on as happens
> from time to time.
>
> * Bootstrap 3 - the UI has been updated to use Bootstrap 3 from version 2 that
> we were using previously. This has made a fairly minor difference to the UI
> (padding/spacing/fonts have changed a little) but has allowed us to tidy up a
> few things in the code.
>
> * The "Base" layer type is no longer selectable for layer submissions. I
> noticed people sometimes selected this erroneously; it's only applicable for
> openembedded-core and meta-oe basically so that they show up at the top of the
> layer list. Only admins can now select this type for a layer.
>
> * Numerous other bugfixes, robustness improvements and code cleanups.
>
> Thanks very much to everyone who has contributed to the layer index code up to
> now (and to BitBake / tinfoil, which we rely upon to extract the information
> from the metadata), but I'd like to give particular thanks to Michael
> Halstead, Yi Zhao, Konrad Scherer, Robert Yang and Aníbal Limón for making
> this upgrade possible.

Paul, and everyone above, many thanks for your contributions to the
Layer Index which is definitely a great tool for our community! It
encourages and simplifies reuse and sharing of all recipes! The update
looks really good, and as Andreas says, the top #3 features will make
a big difference.

>
>
> Also integrated were the Recipe Reporting System (RRS) which powers
> http://recipes.yoctoproject.org and other distro comparison support, but these
> will take a bit more time to properly enable so I'll send out a separate email
> with further details when they are ready.
>
> As always, please let me know if you have any comments or notice any issues.
> (I've already seen a few minor problems in the update logs so I'll be looking
> into those.)
>
> Cheers,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre--
> ___
> yocto mailing list
> yo...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] layers.openembedded.org upgraded

[Andreas Müller]

On Thu, Sep 27, 2018 at 10:42 PM, Paul Eggleton  wrote:
> Hi all,
>
> I'm very happy to announce that we've finally been able to upgrade the layer
> index at http://layers.openembedded.org to the latest revision on master,
> incorporating quite a bit of work that's been going on for the past few
> months. Improvements now visible:
>
> * Patch tracking - each recipe detail page now lists any patches being applied
> by the recipe along with upstream status for each - see attached screenshot.
> You can click through to view/download the actual patch, and any URLs in the
> supplemental status text are also made into clickable links.
>
> * Source tracking - remote entries in SRC_URI are now listed on the recipe
> detail page and made into clickable links where possible - see attached
> screenshot
>
> * Link to inc files - there is now a link in the recipe detail page to any inc
> files that a recipe includes as long as they are in the same directory, as a
> shortcut to see the rest of the definitions for the recipe.
>
> * Recipe list CSV export - there is now an "Export CSV" button at the top of
> the recipe list on the layer detail page. This currently includes the recipe
> name and version - we could look at extending this, but note that the REST API
> provides access to all of the information programmatically and may be better
> suited for many applications that need this data.
>
> * Site-wide notice support - admins can now add notifications to appear at the
> top of the page across the entire site. This is useful in the case where there
> is some problem with the update process or maintenance is going on as happens
> from time to time.
>
> * Bootstrap 3 - the UI has been updated to use Bootstrap 3 from version 2 that
> we were using previously. This has made a fairly minor difference to the UI
> (padding/spacing/fonts have changed a little) but has allowed us to tidy up a
> few things in the code.
>
> * The "Base" layer type is no longer selectable for layer submissions. I
> noticed people sometimes selected this erroneously; it's only applicable for
> openembedded-core and meta-oe basically so that they show up at the top of the
> layer list. Only admins can now select this type for a layer.
>
> * Numerous other bugfixes, robustness improvements and code cleanups.
>
> Thanks very much to everyone who has contributed to the layer index code up to
> now (and to BitBake / tinfoil, which we rely upon to extract the information
> from the metadata), but I'd like to give particular thanks to Michael
> Halstead, Yi Zhao, Konrad Scherer, Robert Yang and Aníbal Limón for making
> this upgrade possible.
>
>
> Also integrated were the Recipe Reporting System (RRS) which powers
> http://recipes.yoctoproject.org and other distro comparison support, but these
> will take a bit more time to properly enable so I'll send out a separate email
> with further details when they are ready.
>
> As always, please let me know if you have any comments or notice any issues.
> (I've already seen a few minor problems in the update logs so I'll be looking
> into those.)
>
> Cheers,
> Paul
>
As daily user of layerindex I think particularly the first three
features are very helpful. Thanks a lot!

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

[OE-core] layers.openembedded.org upgraded

[Paul Eggleton]

Hi all,

I'm very happy to announce that we've finally been able to upgrade the layer 
index at http://layers.openembedded.org to the latest revision on master, 
incorporating quite a bit of work that's been going on for the past few 
months. Improvements now visible:

* Patch tracking - each recipe detail page now lists any patches being applied 
by the recipe along with upstream status for each - see attached screenshot. 
You can click through to view/download the actual patch, and any URLs in the 
supplemental status text are also made into clickable links.

* Source tracking - remote entries in SRC_URI are now listed on the recipe 
detail page and made into clickable links where possible - see attached 
screenshot

* Link to inc files - there is now a link in the recipe detail page to any inc 
files that a recipe includes as long as they are in the same directory, as a 
shortcut to see the rest of the definitions for the recipe.

* Recipe list CSV export - there is now an "Export CSV" button at the top of 
the recipe list on the layer detail page. This currently includes the recipe 
name and version - we could look at extending this, but note that the REST API 
provides access to all of the information programmatically and may be better 
suited for many applications that need this data.

* Site-wide notice support - admins can now add notifications to appear at the 
top of the page across the entire site. This is useful in the case where there 
is some problem with the update process or maintenance is going on as happens 
from time to time.

* Bootstrap 3 - the UI has been updated to use Bootstrap 3 from version 2 that 
we were using previously. This has made a fairly minor difference to the UI 
(padding/spacing/fonts have changed a little) but has allowed us to tidy up a 
few things in the code.

* The "Base" layer type is no longer selectable for layer submissions. I 
noticed people sometimes selected this erroneously; it's only applicable for 
openembedded-core and meta-oe basically so that they show up at the top of the 
layer list. Only admins can now select this type for a layer.

* Numerous other bugfixes, robustness improvements and code cleanups.

Thanks very much to everyone who has contributed to the layer index code up to 
now (and to BitBake / tinfoil, which we rely upon to extract the information 
from the metadata), but I'd like to give particular thanks to Michael 
Halstead, Yi Zhao, Konrad Scherer, Robert Yang and Aníbal Limón for making 
this upgrade possible.


Also integrated were the Recipe Reporting System (RRS) which powers 
http://recipes.yoctoproject.org and other distro comparison support, but these 
will take a bit more time to properly enable so I'll send out a separate email 
with further details when they are ready.

As always, please let me know if you have any comments or notice any issues. 
(I've already seen a few minor problems in the update logs so I'll be looking 
into those.)

Cheers,
Paul

-- 
Paul Eggleton
Intel Open Source Technology Centre-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Run experience with security flags enabled

[Andreas Müller]

On Thu, Sep 27, 2018 at 2:57 PM, Dan McGregor  wrote:
> On Wed, Sep 26, 2018, 15:47 Khem Raj  wrote:
>>
>>
>>
>> On Wed, Sep 26, 2018 at 2:25 PM Andreas Müller 
>> wrote:
>>>
>>> Hi,
>>>
>>> from oe-core perspective my images are build on sumo (glibc 2.27). To
>>> see what to expect, I enabled security flags (and yes some recipes in
>>> my layers needed rework).
>>>
>>> Now that I have an image, I thought: let's give it a run. Apart of
>>> other issues (maybe later) I get on every startup an error message for
>>> ldconfig.
>>> systemctl ldconfig says:
>>>
>>> ● ldconfig.service - Rebuild Dynamic Linker Cache
>>>Loaded: loaded (/lib/systemd/system/ldconfig.service; static;
>>> vendor preset: enabled)
>>>Active: failed (Result: core-dump) since Mon 2018-09-24 19:05:04
>>> UTC; 2 days ago
>>>  Docs: man:ldconfig(8)
>>>   Process: 136 ExecStart=/sbin/ldconfig -X (code=dumped, signal=SEGV)
>>>  Main PID: 136 (code=dumped, signal=SEGV)
>>>
>>> Sep 24 19:05:04 raspberrypi3 systemd[1]: Starting Rebuild Dynamic
>>> Linker Cache...
>>> Sep 24 19:05:04 raspberrypi3 systemd[1]: ldconfig.service: Main
>>> process exited, code=dumped, status=11/SEGV
>>> Sep 24 19:05:04 raspberrypi3 systemd[1]: ldconfig.service: Failed with
>>> result 'core-dump'.
>>> Sep 24 19:05:04 raspberrypi3 systemd[1]: Failed to start Rebuild
>>> Dynamic Linker Cache.
>>>
>>> Again somebody else seeing similar / remembers a fix?
>>
>>
>> I see similar issue in sumo as well
>> I do use security flags too and was not sure if that was the reason I
>> think its a good data point
>> Sadly I don’t yet have looked into the issue in detail
>
>
> GCC 7 and glibc don't play well together with static PIE. The real solution
> is to use GCC 8, but Ross made a workaround for this issue:
>
> http://git.openembedded.org/openembedded-core/commit/?id=5f64946b8740a5d944f48ec430470265703bfe5e
It seems I can confirm this: Debugging shows that the crash happens in
dl-relocate_static-pie.c _dl_relocate_static_pie line 41.

Will send this to sumo as soon as tested.

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

[OE-core] [sumo][PATCH] libsdl2: Fix left rotated display for RaspPi/VC4/GLES2

[Andreas Müller]

The patch should increase performance for libsdl2 on GLES2 too.

(From OE-Core rev: 52f9659f2bb44affec2f67935df01f13b6ff3e02)

Signed-off-by: Andreas Müller 
Signed-off-by: Richard Purdie 
---
 ...01-GLES2-Get-sin-cos-out-of-vertex-shader.patch | 141 +
 meta/recipes-graphics/libsdl2/libsdl2_2.0.8.bb |   1 +
 2 files changed, 142 insertions(+)
 create mode 100644 
meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch

diff --git 
a/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
 
b/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
new file mode 100644
index 00..9b32b3788d
--- /dev/null
+++ 
b/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
@@ -0,0 +1,141 @@
+From c215ba1d52a3d4ef03af3ab1a5baa1863f812aed Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Fri, 24 Aug 2018 23:10:25 +0200
+Subject: [PATCH] GLES2: Get sin/cos out of vertex shader
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The only place angle is activated and causes effect is RenderCopyEx. All other
+methods which use vertex shader, leave angle disabled and cause useless sin/cos
+calculation in shader.
+
+To get around shader's interface is changed to a vector that contains results
+of sin and cos. To behave properly when disabled, cos value is set with offset
+-1.0 making 0.0 default when deactivated.
+
+As nice side effect it simplifies GLES2_UpdateVertexBuffer: All attributes are
+vectors now.
+
+Additional background:
+
+* On RaspberryPi it gives a performace win for operations. Tested with
+  [1] numbers go down for 5-10% (not easy to estimate due to huge variation).
+* SDL_RenderCopyEx was tested with [2]
+* It works around left rotated display caused by low accuracy sin implemetation
+  in RaspberryPi/VC4 [3]
+
+Upstream-Status: Accepted [4]
+
+[1] https://github.com/schnitzeltony/sdl2box
+[2] https://github.com/schnitzeltony/sdl2rendercopyex
+[3] https://github.com/anholt/mesa/issues/110
+[4] https://hg.libsdl.org/SDL/rev/e5a666405750
+
+Signed-off-by: Andreas Müller 
+---
+ src/render/opengles2/SDL_render_gles2.c  | 17 -
+ src/render/opengles2/SDL_shaders_gles2.c | 14 +-
+ 2 files changed, 21 insertions(+), 10 deletions(-)
+
+diff --git a/src/render/opengles2/SDL_render_gles2.c 
b/src/render/opengles2/SDL_render_gles2.c
+index 14671f7c8..7c54a7333 100644
+--- a/src/render/opengles2/SDL_render_gles2.c
 b/src/render/opengles2/SDL_render_gles2.c
+@@ -1530,7 +1530,7 @@ GLES2_UpdateVertexBuffer(SDL_Renderer *renderer, 
GLES2_Attribute attr,
+ GLES2_DriverContext *data = (GLES2_DriverContext *)renderer->driverdata;
+ 
+ #if !SDL_GLES2_USE_VBOS
+-data->glVertexAttribPointer(attr, attr == GLES2_ATTRIBUTE_ANGLE ? 1 : 2, 
GL_FLOAT, GL_FALSE, 0, vertexData);
++data->glVertexAttribPointer(attr, 2, GL_FLOAT, GL_FALSE, 0, vertexData);
+ #else
+ if (!data->vertex_buffers[attr]) {
+ data->glGenBuffers(1, >vertex_buffers[attr]);
+@@ -1545,7 +1545,7 @@ GLES2_UpdateVertexBuffer(SDL_Renderer *renderer, 
GLES2_Attribute attr,
+ data->glBufferSubData(GL_ARRAY_BUFFER, 0, dataSizeInBytes, 
vertexData);
+ }
+ 
+-data->glVertexAttribPointer(attr, attr == GLES2_ATTRIBUTE_ANGLE ? 1 : 2, 
GL_FLOAT, GL_FALSE, 0, 0);
++data->glVertexAttribPointer(attr, 2, GL_FLOAT, GL_FALSE, 0, 0);
+ #endif
+ 
+ return 0;
+@@ -1853,6 +1853,8 @@ GLES2_RenderCopy(SDL_Renderer *renderer, SDL_Texture 
*texture, const SDL_Rect *s
+ return GL_CheckError("", renderer);
+ }
+ 
++#define PI 3.14159265f
++
+ static int
+ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture *texture, const 
SDL_Rect *srcrect,
+  const SDL_FRect *dstrect, const double angle, const 
SDL_FPoint *center, const SDL_RendererFlip flip)
+@@ -1861,8 +1863,9 @@ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture 
*texture, const SDL_Rect
+ GLfloat vertices[8];
+ GLfloat texCoords[8];
+ GLfloat translate[8];
+-GLfloat fAngle[4];
++GLfloat fAngle[8];
+ GLfloat tmp;
++float radian_angle;
+ 
+ GLES2_ActivateRenderer(renderer);
+ 
+@@ -1872,7 +1875,11 @@ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture 
*texture, const SDL_Rect
+ 
+ data->glEnableVertexAttribArray(GLES2_ATTRIBUTE_CENTER);
+ data->glEnableVertexAttribArray(GLES2_ATTRIBUTE_ANGLE);
+-fAngle[0] = fAngle[1] = fAngle[2] = fAngle[3] = (GLfloat)(360.0f - angle);
++
++radian_angle = PI * (360.0f - angle) / 180.f;
++fAngle[0] = fAngle[2] = fAngle[4] = fAngle[6] = 
(GLfloat)sin(radian_angle);
++/* render expects cos value - 1 (see GLES2_VertexSrc_Default_) */
++fAngle[1] = fAngle[3] = fAngle[5] = fAngle[7] = 
(GLfloat)cos(radian_angle) - 1.0f;
+ /* Calculate the center of rotation */
+ translate[0] = translate[2] = translate[4] = 

Re: [OE-core] Run experience with security flags enabled

[Andreas Müller]

On Thu, Sep 27, 2018 at 8:49 PM, Khem Raj  wrote:
> I sent it earlier today see
OK thanks!

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

Re: [OE-core] Run experience with security flags enabled

[Khem Raj]

I sent it earlier today see

https://patchwork.openembedded.org/patch/155216/
On Thu, Sep 27, 2018 at 11:42 AM Andreas Müller  wrote:
>
> On Thu, Sep 27, 2018 at 2:57 PM, Dan McGregor  
> wrote:
> > On Wed, Sep 26, 2018, 15:47 Khem Raj  wrote:
> >>
> >>
> >>
> >> On Wed, Sep 26, 2018 at 2:25 PM Andreas Müller 
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> from oe-core perspective my images are build on sumo (glibc 2.27). To
> >>> see what to expect, I enabled security flags (and yes some recipes in
> >>> my layers needed rework).
> >>>
> >>> Now that I have an image, I thought: let's give it a run. Apart of
> >>> other issues (maybe later) I get on every startup an error message for
> >>> ldconfig.
> >>> systemctl ldconfig says:
> >>>
> >>> ● ldconfig.service - Rebuild Dynamic Linker Cache
> >>>Loaded: loaded (/lib/systemd/system/ldconfig.service; static;
> >>> vendor preset: enabled)
> >>>Active: failed (Result: core-dump) since Mon 2018-09-24 19:05:04
> >>> UTC; 2 days ago
> >>>  Docs: man:ldconfig(8)
> >>>   Process: 136 ExecStart=/sbin/ldconfig -X (code=dumped, signal=SEGV)
> >>>  Main PID: 136 (code=dumped, signal=SEGV)
> >>>
> >>> Sep 24 19:05:04 raspberrypi3 systemd[1]: Starting Rebuild Dynamic
> >>> Linker Cache...
> >>> Sep 24 19:05:04 raspberrypi3 systemd[1]: ldconfig.service: Main
> >>> process exited, code=dumped, status=11/SEGV
> >>> Sep 24 19:05:04 raspberrypi3 systemd[1]: ldconfig.service: Failed with
> >>> result 'core-dump'.
> >>> Sep 24 19:05:04 raspberrypi3 systemd[1]: Failed to start Rebuild
> >>> Dynamic Linker Cache.
> >>>
> >>> Again somebody else seeing similar / remembers a fix?
> >>
> >>
> >> I see similar issue in sumo as well
> >> I do use security flags too and was not sure if that was the reason I
> >> think its a good data point
> >> Sadly I don’t yet have looked into the issue in detail
> >
> >
> > GCC 7 and glibc don't play well together with static PIE. The real solution
> > is to use GCC 8, but Ross made a workaround for this issue:
> >
> > http://git.openembedded.org/openembedded-core/commit/?id=5f64946b8740a5d944f48ec430470265703bfe5e
> It seems I can confirm this: Debugging shows that the crash happens in
> dl-relocate_static-pie.c _dl_relocate_static_pie line 41.
>
> Will send this to sumo as soon as tested.
>
> Andreas
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OpenEmbedded branded T-shirts and Polo shirts!

[Khem Raj]

Thanks for sending this out, these look great
On Thu, Sep 27, 2018 at 8:15 AM Denys Dmytriyenko  wrote:
>
> Besides black and white OpenEmbedded T-shirts and Polos, the shop has also
> added blue ones!
> https://www.hellotux.com/openembedded
>
> Plus, Yocto Project shirts are now available as well:
> https://www.hellotux.com/yocto
>
> --
> Denys
>
>
> On Mon, Jul 02, 2018 at 12:02:16AM -0400, Denys Dmytriyenko wrote:
> > OpenEmbedded branded T-shirts and Polo shirts!
> > Show your support!
> > https://www.hellotux.com/openembedded
> > --
> > ___
> > Openembedded-members mailing list
> > openembedded-memb...@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-members
> --
> ___
> Openembedded-members mailing list
> openembedded-memb...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-members
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] sysklogd: Re-enable alternatives for syslogd.8 man page

[Mark Hatle]

Other recipes, such as meta-networking inetutils may also provide a man page
for syslogd.8.  Use the alternatives mechanism to select the man page to
display.

This is a partial revert of commit: 988aad01b20c18a8850db0ad6dc547525d94116c

The syslogd tool itself is provided by both recipes in their respective runtime
packages.  In the inet case, it is inetutils-syslogd, which has an appropriate
RCONFLICTS with the syslogd version.  Only one or the other will be installed.
This is the conflict resolution the original commit of
"988aad01b20c18a8850db0ad6dc547525d94116c" was referring to.

HOWEVER, both syslogd and inetutils each only have a singular 'doc' package.
(As do most packages it seems.)  Since this is the case, if both syslogd and
inetutils (not syslogd part) is requested for a configuration -- AND ---
doc-pkgs are configured in, you get an error of conflicting files.

Now does the documentation match whichever package was installed, maybe not...
but this isn't a big deal as it turns out, since most syslogd share a common set
of arguments and those are the things a run-time user would query from the man
pages.

The only alternative is to start spliting up the docs into their relevant
subpackages, as we have the runtime items.  But this then complicates the
doc-pkgs processing and related...

Signed-off-by: Mark Hatle 
---
 meta/recipes-extended/sysklogd/sysklogd.inc | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc 
b/meta/recipes-extended/sysklogd/sysklogd.inc
index fc4e67c..f151dd8 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 
file://klogd.c;beginline=2;endline=19;md5=7e87ed0ae6142de079bce738c10c899d \
"
 
-inherit update-rc.d systemd
+inherit update-rc.d update-alternatives systemd
 
 SRC_URI = 
"http://www.infodrom.org/projects/sysklogd/download/sysklogd-${PV}.tar.gz \
file://no-strip-install.patch \
@@ -58,6 +58,11 @@ do_install () {
 
 FILES_${PN} += 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${exec_prefix}/lib/tmpfiles.d/sysklogd.conf',
 '', d)}"
 
+ALTERNATIVE_PRIORITY = "100"
+
+ALTERNATIVE_${PN}-doc = "syslogd.8"
+ALTERNATIVE_LINK_NAME[syslogd.8] = "${mandir}/man8/syslogd.8"
+
 pkg_prerm_${PN} () {
if test "x$D" = "x"; then
if test "$1" = "upgrade" -o "$1" = "remove"; then
-- 
1.8.3.1

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

Re: [OE-core] [PATCH] sysklogd.inc: add syslogd.8 to ALTERNATIVE_${PN}-doc

[richard . purdie]

On Thu, 2018-09-27 at 10:19 -0500, Mark Hatle wrote:
> On 9/27/18 4:36 AM, richard.pur...@linuxfoundation.org wrote:
> > On Thu, 2018-09-27 at 13:22 +0800, mingli...@windriver.com wrote:
> > > From: Mark Hatle 
> > > 
> > > Other recipes, such as meta-networking inetutils
> > > may also provide a man page for syslogd.8.
> > > Use the alternatives mechanism to select the man
> > > page to display.
> > > 
> > > This is a partial revert of commit:
> > > 988aad01b20c18a8850db0ad6dc547525d94116c
> > > 
> > > Signed-off-by: Mark Hatle 
> > > Signed-off-by: Mingli Yu 
> > > ---
> > >  meta/recipes-extended/sysklogd/sysklogd.inc | 6 +-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > I'm not sure I like the sound of this. Why would it provide a man
> > page
> > but not the actual tool itself?
> > 
> > At the very least this needs a better explanation but I'm not sure
> > it
> > sounds correct or is something we want to encourage.
> 
> The syslogd 'tool' is provided by both recipes in their respective 'runtime'
> packages.  In the inet case, it is inetutils-syslogd, which has an appropriate
> RCONFLICTS with the syslogd version.  So only one or the other will be
> installed.  This is the conflict resolution the original commit of
> "988aad01b20c18a8850db0ad6dc547525d94116c" was referring to.
> 
> HOWEVER, both syslogd and inetutils each only have a singular 'doc' package.
> (As do most packages it seems.)  Since this is the case, there and syslogd and
> inetutils (not syslogd part) is requested for this configuration -- AND ---
> doc-pkgs are configured in, you get an error of conflicting files.
> 
> Thus a partial revert of the prior work enabled documentation to be installed
> correctly.
> 
> Now does the documentation match whichever package was installed, maybe not...
> but this isn't a big deal as it turns out, since most syslogd share a common 
> set
> of arguments and those are the things a run-time user would query from the man
> pages.
> 
> The only alternative is to start spliting up the docs into their relevant
> subpackages, as we have the runtime items.  But this then complicates the
> doc-pkgs processing and related...

This makes much more sense with more information. Could someone rewrite
the commit message please?

Cheers,

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

Re: [OE-core] [PATCH] sysklogd.inc: add syslogd.8 to ALTERNATIVE_${PN}-doc

[Mark Hatle]

On 9/27/18 4:36 AM, richard.pur...@linuxfoundation.org wrote:
> On Thu, 2018-09-27 at 13:22 +0800, mingli...@windriver.com wrote:
>> From: Mark Hatle 
>>
>> Other recipes, such as meta-networking inetutils
>> may also provide a man page for syslogd.8.
>> Use the alternatives mechanism to select the man
>> page to display.
>>
>> This is a partial revert of commit:
>> 988aad01b20c18a8850db0ad6dc547525d94116c
>>
>> Signed-off-by: Mark Hatle 
>> Signed-off-by: Mingli Yu 
>> ---
>>  meta/recipes-extended/sysklogd/sysklogd.inc | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> I'm not sure I like the sound of this. Why would it provide a man page
> but not the actual tool itself?
> 
> At the very least this needs a better explanation but I'm not sure it
> sounds correct or is something we want to encourage.

The syslogd 'tool' is provided by both recipes in their respective 'runtime'
packages.  In the inet case, it is inetutils-syslogd, which has an appropriate
RCONFLICTS with the syslogd version.  So only one or the other will be
installed.  This is the conflict resolution the original commit of
"988aad01b20c18a8850db0ad6dc547525d94116c" was referring to.

HOWEVER, both syslogd and inetutils each only have a singular 'doc' package.
(As do most packages it seems.)  Since this is the case, there and syslogd and
inetutils (not syslogd part) is requested for this configuration -- AND ---
doc-pkgs are configured in, you get an error of conflicting files.

Thus a partial revert of the prior work enabled documentation to be installed
correctly.

Now does the documentation match whichever package was installed, maybe not...
but this isn't a big deal as it turns out, since most syslogd share a common set
of arguments and those are the things a run-time user would query from the man
pages.

The only alternative is to start spliting up the docs into their relevant
subpackages, as we have the runtime items.  But this then complicates the
doc-pkgs processing and related...

--Mark

> Cheers,
> 
> Richard
> 

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

Re: [OE-core] OpenEmbedded branded T-shirts and Polo shirts!

[Denys Dmytriyenko]

Besides black and white OpenEmbedded T-shirts and Polos, the shop has also 
added blue ones!
https://www.hellotux.com/openembedded

Plus, Yocto Project shirts are now available as well:
https://www.hellotux.com/yocto

-- 
Denys


On Mon, Jul 02, 2018 at 12:02:16AM -0400, Denys Dmytriyenko wrote:
> OpenEmbedded branded T-shirts and Polo shirts!
> Show your support!
> https://www.hellotux.com/openembedded
> -- 
> ___
> Openembedded-members mailing list
> openembedded-memb...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-members
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] glibc-package.inc: correct intention for deleting /usr/lib as needed

[Awais Belal]

In case the baselib is lib64 we would want to delete /usr/lib
after removing the /usr/lib/locale dir and the implementation
wanted to do that earlier as well but the fault was checking
an already removed dir (/usr/lib/locale) before trying to
remove /usr/lib as that check would always fail.
Now we simply try to delete /usr/lib after deleting
/usr/lib/locale to make sure it deletes cleanly and is empty
at the time of deletion.

Signed-off-by: Awais Belal 
---
 meta/recipes-core/glibc/glibc-package.inc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 9ea41b7..a98ae1a 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -207,10 +207,11 @@ do_poststash_install_cleanup () {
rm -rf ${D}/${localedir}
rm -rf ${D}${datadir}/locale
if [ "${libdir}" != "${exec_prefix}/lib" ]; then
-   if [ -d ${D}${exec_prefix}/lib/locale ] ; then
-   rm -rf ${D}${exec_prefix}/lib/locale
+   if [ -d ${D}${exec_prefix}/lib ]; then
# error out if directory isn't empty
-   rm -f ${D}${exec_prefix}/lib
+   # this dir should only contain locale dir
+   # which has been deleted in the previous step
+   rmdir ${D}${exec_prefix}/lib
fi
fi
 }
-- 
2.7.4

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

[OE-core] [sumo][PATCH] security_flags: disable static PIE in glibc

[Khem Raj]

From: Ross Burton 

Static PIE doesn't work entirely right in GCC 7, for example ldconfig on ARM
with the flags enabled will something segfault during initialisation.

To mitigate this until we have GCC 8 integrated, don't enable static PIE.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/security_flags.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index d66dd57649..aaeca6991b 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -6,7 +6,7 @@
 # in the DISTRO="poky-lsb" configuration.
 
 GCCPIE ?= "--enable-default-pie"
-GLIBCPIE ?= "--enable-static-pie"
+# If static PIE is known to work well, GLIBCPIE="--enable-static-pie" can be 
set
 
 # _FORTIFY_SOURCE requires -O1 or higher, so disable in debug builds as they 
use
 # -O0 which then results in a compiler warning.
-- 
2.19.0

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

Re: [OE-core] Run experience with security flags enabled

[Dan McGregor]

On Wed, Sep 26, 2018, 15:47 Khem Raj  wrote:

>
>
> On Wed, Sep 26, 2018 at 2:25 PM Andreas Müller 
> wrote:
>
>> Hi,
>>
>> from oe-core perspective my images are build on sumo (glibc 2.27). To
>> see what to expect, I enabled security flags (and yes some recipes in
>> my layers needed rework).
>>
>> Now that I have an image, I thought: let's give it a run. Apart of
>> other issues (maybe later) I get on every startup an error message for
>> ldconfig.
>> systemctl ldconfig says:
>>
>> ● ldconfig.service - Rebuild Dynamic Linker Cache
>>Loaded: loaded (/lib/systemd/system/ldconfig.service; static;
>> vendor preset: enabled)
>>Active: failed (Result: core-dump) since Mon 2018-09-24 19:05:04
>> UTC; 2 days ago
>>  Docs: man:ldconfig(8)
>>   Process: 136 ExecStart=/sbin/ldconfig -X (code=dumped, signal=SEGV)
>>  Main PID: 136 (code=dumped, signal=SEGV)
>>
>> Sep 24 19:05:04 raspberrypi3 systemd[1]: Starting Rebuild Dynamic
>> Linker Cache...
>> Sep 24 19:05:04 raspberrypi3 systemd[1]: ldconfig.service: Main
>> process exited, code=dumped, status=11/SEGV
>> Sep 24 19:05:04 raspberrypi3 systemd[1]: ldconfig.service: Failed with
>> result 'core-dump'.
>> Sep 24 19:05:04 raspberrypi3 systemd[1]: Failed to start Rebuild
>> Dynamic Linker Cache.
>>
>> Again somebody else seeing similar / remembers a fix?
>>
>
> I see similar issue in sumo as well
> I do use security flags too and was not sure if that was the reason I
> think its a good data point
> Sadly I don’t yet have looked into the issue in detail
>

GCC 7 and glibc don't play well together with static PIE. The real solution
is to use GCC 8, but Ross made a workaround for this issue:

http://git.openembedded.org/openembedded-core/commit/?id=5f64946b8740a5d944f48ec430470265703bfe5e


>
>>
>> Help appreciated
>>
>> Andreas
>> --
>> ___
>> 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] [RFC][PATCH] bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

[Martin Jansa]

The reason is that for our builds we set the IMAGE_VERSION_SUFFIX based on
jenkins job number which creates them (or you can
imagine IMAGE_VERSION_SUFFIX being set to something like "release-2.6").

With current metadata we have 2 options:
1) keep IMAGE_VERSION_SUFFIX as is, but don't vardepexclude the build
number (DATETIME in the default value)
But this causes e.g. kernel.do_deploy signature to be changed and whole
do_deploy task re-executed (instead of reused from sstate if it's the same
except the output files names), which in turn causes whole kernel to be
rebuilt in every build, because to run do_deploy we need do_install etc
(and these builds are usually using rm_work and TMPDIR is empty before each
job).

2) leave IMAGE_VERSION_SUFFIX as is, but rename the artifacts after the
build
When the image artifact says "image-release-2.6.img" and kernel image from
the same build says "uImage-release-2.5.bin" (because kernel wasn't
modified at all since previous release), people will be confused.
This is what we were seeing in CI which was usually sending just the image,
but then for some new MACHINEs we needed to send kernel artifact separately
and sometimes the artifact wasn't found with expected name.
Then we changed the build number (aka IMAGE_VERSION_SUFFIX) to be included
in do_deploy signatures which lead to 1) and kernel rebuilds every time

To solve both, we've added webos_deploy_fixup tasks (in many places) which
just adds the hardlinks with expected filenames (so that other systems just
using the artifacts doesn't need to know anything about internal issues
with sstate reuse, nor needing external script to rename things after the
build).

Hardlinks are better than symlinks in this case, because you don't want to
have symlink
image-release-2.5.img -> image.img
still in the deploy directory after you do another build which creates new
image.img and new symlink
image-release-2.6.img -> image.img

If someone downloads image-release-2.5.img "too late" he will get 2.6
version instead.

Hardlinks don't have this issue and yes the need to check the inode numbers
might be confusing to some, but when do you really care where does it
point? In our use-case we always care only about the *"release-2.5"* and
the artifacts without the version string are considered as intermediate
files created by the build or "whatever version was built last in this
build directory", pretty much the same as version-less symlinks in current
build (which are easy to resolve when looking at the filesystem, but
exposing those symlinks for download e.g. over HTTP hides where it points
completely.

I'm not sure I understand your concern about bypassing sstate control, we
still want to reuse kernel.do_deploy and image.do_image_complete. Just with
additional very fast intentionally not-covered-by-sstate task before
do_build to create consistent names.

On Thu, Sep 27, 2018 at 1:15 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> Hi Martin,
>
> In the commit message you say a lot about what you've changed but not
> so much about why the changes are important and the advantages they
> bring.
>
> There are tradeoffs, for example symlinks make it clear which artefact
> they're really pointing at, hardlinks hide that fact, you need to go
> and look at inode numbers to figure out which of several artefacts one
> might be pointing at. I'm not sure that is an improvement.
>
> I'm also slightly concerned that we need to bypass sstate control, the
> whole intent there was to ensure that output is reproducible and
> consistently restored. Adding in a new task means do_build target usage
> will work but any of the code that has do_deploy as a dependency (e.g.
> an recrdep) will now also need to consider do_deploy_links. For that
> reason alone, I'm not sure we can do this.
>
> Cheers,
>
> Richard
>
> On Thu, 2018-09-27 at 09:11 +, Martin Jansa wrote:
> > * just RFC, the part for images isn't finished yet and there is
> >   still some issue with DATETIME when kernel artifacts are used
> >   from sstate, this is just to validate the idea behind
> >   [YOCTO #12937] before finishing the implementation (it's already
> >   finished and used by various LGE builds, but having simpler
> >   way of doing it directly in oe-core mighe be useful for others).
> >
> > * move IMAGE_VERSION_SUFFIX from _NAME variables to _LINK_NAME
> >   that way e.g. kernel.do_deploy can be reused from sstate to
> >   provide "version-less" artifacts and then very fast
> >   do_deploy_links task just adds links with consistent suffixes
> > * create hard links instead of symlinks, so that whatever version
> >   the filename says is really there
> > * some IMAGE_FSTYPES might need the "version-less" IMAGE_NAME file
> >   to be removed first or they might either append or update the
> >   content of the image instead of creating new image file from
> >   scratch - I have seen this only with one proprietary format we
> >   generate with our own tool, so 

Re: [OE-core] [PATCH] glibc-package.inc: correct intention for deleting /usr/lib as needed

[Richard Purdie]

On Thu, 2018-09-27 at 09:03 +, Belal, Awais wrote:
> When do you think this would go in?

Its not going in, it doesn't build and broke things.

I thought someone had reported back but that hasn't happened, sorry.
Getting SWAT on the autobuilder to happen reliably is proving tricky
right now :(.

An example failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/2/builds/62/steps/7/logs/step1b

I think we aborted that build run after the errors:
https://autobuilder.yoctoproject.org/typhoon/#/builders/6/builds/71
so most say cancelled but I think other errors were piling up.

Cheers,

Richard



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

Re: [OE-core] [RFC][PATCH] bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

[Richard Purdie]

Hi Martin,

In the commit message you say a lot about what you've changed but not
so much about why the changes are important and the advantages they
bring.

There are tradeoffs, for example symlinks make it clear which artefact
they're really pointing at, hardlinks hide that fact, you need to go
and look at inode numbers to figure out which of several artefacts one
might be pointing at. I'm not sure that is an improvement.

I'm also slightly concerned that we need to bypass sstate control, the
whole intent there was to ensure that output is reproducible and
consistently restored. Adding in a new task means do_build target usage
will work but any of the code that has do_deploy as a dependency (e.g.
an recrdep) will now also need to consider do_deploy_links. For that
reason alone, I'm not sure we can do this.

Cheers,

Richard

On Thu, 2018-09-27 at 09:11 +, Martin Jansa wrote:
> * just RFC, the part for images isn't finished yet and there is
>   still some issue with DATETIME when kernel artifacts are used
>   from sstate, this is just to validate the idea behind
>   [YOCTO #12937] before finishing the implementation (it's already
>   finished and used by various LGE builds, but having simpler
>   way of doing it directly in oe-core mighe be useful for others).
> 
> * move IMAGE_VERSION_SUFFIX from _NAME variables to _LINK_NAME
>   that way e.g. kernel.do_deploy can be reused from sstate to
>   provide "version-less" artifacts and then very fast
>   do_deploy_links task just adds links with consistent suffixes
> * create hard links instead of symlinks, so that whatever version
>   the filename says is really there
> * some IMAGE_FSTYPES might need the "version-less" IMAGE_NAME file
>   to be removed first or they might either append or update the
>   content of the image instead of creating new image file from
>   scratch - I have seen this only with one proprietary format we
>   generate with our own tool, so hopefully this isn't very common
> * this is basically the mechanism are using in webOS with
>   WEBOS_IMAGE_NAME_SUFFIX which is for official builds set from
>   jenkins job and then all artifacts (images as well as corresponding
>   kernel files) have the same version string, the implementation
>   "from outside" is a bit tricky as shown in webOS OSE, the variable
>   modifications:
>   https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e
> 44a132d01297ff478248/meta-webos/conf/distro/include/webos.inc#L65
>   and then various bbclasses to hook do_webos_deploy_fixup task
> creating
>   the hardlinks for possible artifacts:
>   https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e
> 44a132d01297ff478248/meta-webos/classes/webos_deploy.bbclass
>   https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e
> 44a132d01297ff478248/meta-webos/classes/kernel.bbclass
>   https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e
> 44a132d01297ff478248/meta-webos/classes/image.bbclass
>   so hopefully with all these changes in oe-core other project can
>   achieve the same just by setting one variable IMAGE_VERSION_SUFFIX
> 
> [YOCTO #12937]
> 
> Signed-off-by: Martin Jansa 
> ---
>  meta/classes/kernel-artifact-names.bbclass |  4 +--
>  meta/classes/kernel.bbclass| 40 --
> 
>  meta/conf/bitbake.conf |  4 +--
>  3 files changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/meta/classes/kernel-artifact-names.bbclass
> b/meta/classes/kernel-artifact-names.bbclass
> index bbeecba7bd..84ec193b5a 100644
> --- a/meta/classes/kernel-artifact-names.bbclass
> +++ b/meta/classes/kernel-artifact-names.bbclass
> @@ -1,5 +1,5 @@
> -KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-
> ${MACHINE}${IMAGE_VERSION_SUFFIX}"
> -KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
> +KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}"
> +KERNEL_ARTIFACT_LINK_NAME ?=
> "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
>  
>  KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
>  KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
> diff --git a/meta/classes/kernel.bbclass
> b/meta/classes/kernel.bbclass
> index d0fbbd1989..7aaebb56b4 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -667,25 +667,18 @@ kernel_do_deploy() {
>   fi
>  
>   for imageType in ${KERNEL_IMAGETYPES} ; do
> - base_name=${imageType}-${KERNEL_IMAGE_NAME}
> - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
> $deployDir/${base_name}.bin
> - symlink_name=${imageType}-${KERNEL_IMAGE_LINK_NAME}
> - ln -sf ${base_name}.bin
> $deployDir/${symlink_name}.bin
> - ln -sf ${base_name}.bin $deployDir/${imageType}
> + install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
> $deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin
> + ln -sf ${imageType}-${KERNEL_IMAGE_NAME}.bin
> $deployDir/${imageType}
>   done
>  
>   if [ 

Re: [OE-core] [PATCH] sysklogd.inc: add syslogd.8 to ALTERNATIVE_${PN}-doc

[richard . purdie]

On Thu, 2018-09-27 at 13:22 +0800, mingli...@windriver.com wrote:
> From: Mark Hatle 
> 
> Other recipes, such as meta-networking inetutils
> may also provide a man page for syslogd.8.
> Use the alternatives mechanism to select the man
> page to display.
> 
> This is a partial revert of commit:
> 988aad01b20c18a8850db0ad6dc547525d94116c
> 
> Signed-off-by: Mark Hatle 
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-extended/sysklogd/sysklogd.inc | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

I'm not sure I like the sound of this. Why would it provide a man page
but not the actual tool itself?

At the very least this needs a better explanation but I'm not sure it
sounds correct or is something we want to encourage.

Cheers,

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

Re: [OE-core] [PATCH] nativesdk-bison: Add to nativesdk-packagegroup-sdk-host and set BISON_PKGDATADIR

[He Zhe]

Please ignore. Something wrong with it.

Zhe

On 2018年09月27日 16:38, zhe...@windriver.com wrote:
> From: He Zhe 
>
> bison is needed when building kernel. Add it to 
> nativesdk-packagegroup-sdk-host
> and set BISON_PKGDATADIR for bison to use its components.
>
> Signed-off-by: He Zhe 
> ---
>  meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
>  meta/recipes-devtools/bison/bison_3.0.4.bb | 4 
>  2 files changed, 5 insertions(+)
>
> diff --git 
> a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
> b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> index e2f6169..448c2f6 100644
> --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> @@ -25,6 +25,7 @@ RDEPENDS_${PN} = "\
>  nativesdk-cmake \
>  ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
> '', d)} \
>  nativesdk-sdk-provides-dummy \
> +nativesdk-bison \
>  "
>  
>  RDEPENDS_${PN}_darwin = "\
> diff --git a/meta/recipes-devtools/bison/bison_3.0.4.bb 
> b/meta/recipes-devtools/bison/bison_3.0.4.bb
> index cc155f0..07677a7 100644
> --- a/meta/recipes-devtools/bison/bison_3.0.4.bb
> +++ b/meta/recipes-devtools/bison/bison_3.0.4.bb
> @@ -36,4 +36,8 @@ do_install_append_class-native() {
>   create_wrapper ${D}/${bindir}/bison \
>   BISON_PKGDATADIR=${STAGING_DATADIR_NATIVE}/bison
>  }
> +do_install_append_class-nativesdk() {
> + create_wrapper ${D}/${bindir}/bison \
> + 
> BISON_PKGDATADIR=${OECORE_NATIVE_SYSROOT}${prefix_nativesdk}/share/bison
> +}
>  BBCLASSEXTEND = "native nativesdk"

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

[OE-core] ✗ patchtest: failure for bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

[Patchwork]

== Series Details ==

Series: bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the 
_LINK_NAME variables and change it to hard link
Revision: 1
URL   : https://patchwork.openembedded.org/series/14258/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[RFC] bitbake.conf, kernel*.bbclass: include 
IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link
 Issue Commit shortlog is too long [test_shortlog_length] 
  Suggested fixEdit shortlog so that it is 90 characters or less (currently 
119 characters)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [RFC][PATCH] bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

[Martin Jansa]

* just RFC, the part for images isn't finished yet and there is
  still some issue with DATETIME when kernel artifacts are used
  from sstate, this is just to validate the idea behind
  [YOCTO #12937] before finishing the implementation (it's already
  finished and used by various LGE builds, but having simpler
  way of doing it directly in oe-core mighe be useful for others).

* move IMAGE_VERSION_SUFFIX from _NAME variables to _LINK_NAME
  that way e.g. kernel.do_deploy can be reused from sstate to
  provide "version-less" artifacts and then very fast
  do_deploy_links task just adds links with consistent suffixes
* create hard links instead of symlinks, so that whatever version
  the filename says is really there
* some IMAGE_FSTYPES might need the "version-less" IMAGE_NAME file
  to be removed first or they might either append or update the
  content of the image instead of creating new image file from
  scratch - I have seen this only with one proprietary format we
  generate with our own tool, so hopefully this isn't very common
* this is basically the mechanism are using in webOS with
  WEBOS_IMAGE_NAME_SUFFIX which is for official builds set from
  jenkins job and then all artifacts (images as well as corresponding
  kernel files) have the same version string, the implementation
  "from outside" is a bit tricky as shown in webOS OSE, the variable
  modifications:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/conf/distro/include/webos.inc#L65
  and then various bbclasses to hook do_webos_deploy_fixup task creating
  the hardlinks for possible artifacts:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/webos_deploy.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/kernel.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/image.bbclass
  so hopefully with all these changes in oe-core other project can
  achieve the same just by setting one variable IMAGE_VERSION_SUFFIX

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel-artifact-names.bbclass |  4 +--
 meta/classes/kernel.bbclass| 40 --
 meta/conf/bitbake.conf |  4 +--
 3 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/meta/classes/kernel-artifact-names.bbclass 
b/meta/classes/kernel-artifact-names.bbclass
index bbeecba7bd..84ec193b5a 100644
--- a/meta/classes/kernel-artifact-names.bbclass
+++ b/meta/classes/kernel-artifact-names.bbclass
@@ -1,5 +1,5 @@
-KERNEL_ARTIFACT_NAME ?= 
"${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}"
+KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
 
 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
 KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index d0fbbd1989..7aaebb56b4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -667,25 +667,18 @@ kernel_do_deploy() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   base_name=${imageType}-${KERNEL_IMAGE_NAME}
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${base_name}.bin
-   symlink_name=${imageType}-${KERNEL_IMAGE_LINK_NAME}
-   ln -sf ${base_name}.bin $deployDir/${symlink_name}.bin
-   ln -sf ${base_name}.bin $deployDir/${imageType}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin
+   ln -sf ${imageType}-${KERNEL_IMAGE_NAME}.bin 
$deployDir/${imageType}
done
 
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}${root_prefix}/lib
tar -cvzf $deployDir/modules-${MODULE_TARBALL_NAME}.tgz -C 
${D}${root_prefix} lib
-   ln -sf modules-${MODULE_TARBALL_NAME}.tgz 
$deployDir/modules-${MODULE_TARBALL_LINK_NAME}.tgz
fi
 
if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; 
then
for imageType in ${KERNEL_IMAGETYPES} ; do
-   initramfs_base_name=${imageType}-${INITRAMFS_NAME}
-   
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
-   install -m 0644 
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs 
$deployDir/${initramfs_base_name}.bin
-   ln -sf ${initramfs_base_name}.bin 
$deployDir/${initramfs_symlink_name}.bin
+   install -m 0644 
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs 
$deployDir/${imageType}-${INITRAMFS_NAME}.bin
done
fi
 }
@@ 

Re: [OE-core] [PATCH] glibc-package.inc: correct intention for deleting /usr/lib as needed

[Belal, Awais]

Hi Ross,

When do you think this would go in?

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Friday, September 21, 2018 6:31 PM
To: Burton, Ross
Cc: OE-core
Subject: Re: [OE-core] [PATCH] glibc-package.inc: correct intention for 
deleting /usr/lib as needed

>> That's better than HTML!
Attached.

BR,
Awais


From: Burton, Ross 
Sent: Thursday, September 20, 2018 7:46 PM
To: Belal, Awais
Cc: OE-core
Subject: Re: [OE-core] [PATCH] glibc-package.inc: correct intention for 
deleting /usr/lib as needed

That's better than HTML!
On Thu, 20 Sep 2018 at 15:04, Belal, Awais  wrote:
>
> Hi Ross,
>
> >> Can you resend using git-send-email, as this patch is encoded in HTML.
> My SMTP server is acting up these days, should I simply resend the patch here 
> as an attachment?
>
> BR,
> Awais
>
> 
> From: Burton, Ross [ross.bur...@intel.com]
> Sent: Thursday, September 20, 2018 4:10 PM
> To: Belal, Awais
> Cc: OE-core
> Subject: Re: [OE-core] [PATCH] glibc-package.inc: correct intention for 
> deleting /usr/lib as needed
>
> Can you resend using git-send-email, as this patch is encoded in HTML.
>
> Ross
> On Tue, 18 Sep 2018 at 11:53, Belal, Awais  wrote:
> >
> > In case the baselib is lib64 we would want to delete /usr/lib
> > after removing the /usr/lib/locale dir and the implementation
> > wanted to do that earlier as well but the fault was checking
> > an already removed dir (/usr/lib/locale) before trying to
> > remove /usr/lib as that check would always fail.
> > Now we simply try to delete /usr/lib after deleting
> > /usr/lib/locale to make sure it deletes cleanly and is empty
> > at the time of deletion.
> >
> > Signed-off-by: Awais Belal 
> > ---
> >  meta/recipes-core/glibc/glibc-package.inc | 9 -
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/meta/recipes-core/glibc/glibc-package.inc 
> > b/meta/recipes-core/glibc/glibc-package.inc
> > index 9ea41b7..22a59d2 100644
> > --- a/meta/recipes-core/glibc/glibc-package.inc
> > +++ b/meta/recipes-core/glibc/glibc-package.inc
> > @@ -207,11 +207,10 @@ do_poststash_install_cleanup () {
> >  rm -rf ${D}/${localedir}
> >  rm -rf ${D}${datadir}/locale
> >  if [ "${libdir}" != "${exec_prefix}/lib" ]; then
> > -if [ -d ${D}${exec_prefix}/lib/locale ] ; then
> > -rm -rf ${D}${exec_prefix}/lib/locale
> > -# error out if directory isn't empty
> > -rm -f ${D}${exec_prefix}/lib
> > -fi
> > +# error out if directory isn't empty
> > +# this dir should only contain locale dir
> > +# which has been deleted in the previous step
> > +rmdir ${D}${exec_prefix}/lib
> >  fi
> >  }
> >  addtask do_poststash_install_cleanup after do_stash_locale do_install 
> > before do_populate_sysroot do_package
> > --
> > 2.7.4
> >
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2 1/1] nativesdk.bbclass: set consistent staging dirs regardless of multilib

[Chen Qi]

For now, the RECIPE_SYSROOT of nativesdk recipes is ${WORKDIR}/recipe-sysroot
if multilib is disabled and ${WORKDIR}/nativesdk-recipe-sysroot if multilib
is enabled. And it's causing chaos. Problems I've met include:
1) 'File Exists' error when doing extend_recipe_sysroot
2) Rebuilding failure about cmake based nativesdk recipes if toggling multilib

In nativesdk.bbclass, We've set MULTILIBS to be "", and we've changed MLPREFIX
to be 'nativesdk-', I think we should also set consistent RECIPE_SYSROOT to be
${WORKDIR}/recipe-sysroot.

Below is an example showing why previous settings will cause 
do_prepare_recipe_sysroot
failure.

e.g.
A -> C
B -> C
A's RECIPE_SYSROOT is .../recipe-sysroot and B's RECIPE_SYSROOT is
.../nativesdk-recipe-sysroot.
As extend_recipe_sysroot function uses shared manifest, i.e., the same
manifest of C for both A and B, then there must be one of them having
the wrong manifest. And the wrong manifest results in RECIPE_SYSROOT
not cleaned up before installing new components, thus the following error.

  Exception: FileExistsError: [Errno 17] File exists: xxx -> xxx

This happens when toggling multilib and also between nativesdk recipes and
crosssdk, cross-canadian recipes. The latter situation also explains
why choosing ${WORKDIR}/recipe-sysroot instead of 
${WORKDIR}/nativesdk-recipe-sysroot.
If we use 'nativesdk-recipe-sysroot', we still need to modify the 
extend_recipe_sysroot
function to treat crosssdk and cross-canadian as special cases. Using
'recipe-sysroot' does not have this problem.

Signed-off-by: Chen Qi 
---
 meta/classes/nativesdk.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index ab566e9..f25b0c3 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -12,6 +12,11 @@ MACHINEOVERRIDES = ""
 
 MULTILIBS = ""
 
+# we need consistent staging dir whether or not multilib is enabled
+STAGING_DIR_HOST = "${WORKDIR}/recipe-sysroot"
+STAGING_DIR_TARGET = "${WORKDIR}/recipe-sysroot"
+RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"
+
 #
 # Update PACKAGE_ARCH and PACKAGE_ARCHS
 #
-- 
1.9.1

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

[OE-core] [PATCH V2 0/1] nativesdk.bbclass: set consistent staging dirs regardless of multilib

[Chen Qi]

Changes in V2:
* use 'recipe-sysroot' instead of 'nativesdk-recipe-sysroot'

The following changes since commit 5cd00e3e53819f3c10d1733480077ce9f3cc2ca8:

  bitbake: fetch2/gitsm.py: Rework the git submodule fetcher (2018-09-26 
15:14:33 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/nativesdk-recipe-sysroot
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/nativesdk-recipe-sysroot

Chen Qi (1):
  nativesdk.bbclass: set consistent staging dirs regardless of multilib

 meta/classes/nativesdk.bbclass | 5 +
 1 file changed, 5 insertions(+)

-- 
1.9.1

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

[OE-core] [PATCH] nativesdk-bison: Add to nativesdk-packagegroup-sdk-host and set BISON_PKGDATADIR

[zhe.he]

From: He Zhe 

bison is needed when building kernel. Add it to nativesdk-packagegroup-sdk-host
and set BISON_PKGDATADIR for bison to use its components.

Signed-off-by: He Zhe 
---
 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
 meta/recipes-devtools/bison/bison_3.0.4.bb | 4 
 2 files changed, 5 insertions(+)

diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index e2f6169..448c2f6 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -25,6 +25,7 @@ RDEPENDS_${PN} = "\
 nativesdk-cmake \
 ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
'', d)} \
 nativesdk-sdk-provides-dummy \
+nativesdk-bison \
 "
 
 RDEPENDS_${PN}_darwin = "\
diff --git a/meta/recipes-devtools/bison/bison_3.0.4.bb 
b/meta/recipes-devtools/bison/bison_3.0.4.bb
index cc155f0..07677a7 100644
--- a/meta/recipes-devtools/bison/bison_3.0.4.bb
+++ b/meta/recipes-devtools/bison/bison_3.0.4.bb
@@ -36,4 +36,8 @@ do_install_append_class-native() {
create_wrapper ${D}/${bindir}/bison \
BISON_PKGDATADIR=${STAGING_DATADIR_NATIVE}/bison
 }
+do_install_append_class-nativesdk() {
+   create_wrapper ${D}/${bindir}/bison \
+   
BISON_PKGDATADIR=${OECORE_NATIVE_SYSROOT}${prefix_nativesdk}/share/bison
+}
 BBCLASSEXTEND = "native nativesdk"
-- 
2.7.4

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

Re: [OE-core] glibc binary reproducibility

[Richard Purdie]

On Thu, 2018-09-27 at 12:18 +1200, Douglas Royds wrote:
> > $ arm-tait-linux-gnueabi-gcc  -march=armv5te -marm -mcpu=arm926ej-s 
> > --sysroot=/home/douglas/workspace/upstream1/build/tmp/work/armv5e-
> > tait-linux-gnueabi/glibc/2.28-r0/recipe-sysroot -nostdlib
> > -nostartfiles -r -o
> > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-
> > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/crt1.o
> > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-
> > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/start.o
> > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-
> > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/abi-note.o
> > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-
> > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/init.o
> > /home/douglas/workspace/upstream1/build/tmp/work/armv5e-tait-linux-
> > gnueabi/glibc/2.28-r0/build-arm-tait-linux-gnueabi/csu/static-
> > reloc.o
> 
> Note the -r = --relocatable, an ld option, which, "Generate[s]
> relocatable output---i.e., generate[s] an output file that can in
> turn serve as input to ld.  This is often called partial linking",
> ie. the glibc build is just putting these .o files together for later
> convenience.
> Regrettably, this command both ignores -fdebug-prefix-map (which ld
> doesn't accept) and puts the fully-qualified path to some of the
> input .o files in the resulting crt1.o. At package splitdebuginfo()
> time, although the fully-qualified path info is split off into the
> .debug files, a (relative) path to the .debug files plus a checksum
> is tacked onto libc.so by objcopy --add-gnu-debuglink ... and the
> checksum depends on the path to the build.
> There is a work-around: turn off the debug packaging:
> > INHIBIT_PACKAGE_DEBUG_SPLIT_pn-glibc = "1"
> 
> I don't have a solution for this. Suggestions?

Good work in tracking it down so far.

Going off a bit of a random memory fragment, would it help to use
relative paths in the compile/link command?

Cheers,

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

Re: [OE-core] [PATCH 0/2] Fix install file conflicts of gobject-introspection when multilib is enabled

[Kang Kai]

On 2018年09月17日 17:43, Kai Kang wrote:

Some of .gir files are target related, so install .gir files to ${libdir}
rather than ${datadir} to fix install file conflicts when mutlilib is enabled.

The following changes since commit b78597a4e038ed64b379f11257002e5a5f24886f:

   xf86-video-fbdev: update to 0.5.0 (2018-09-17 08:41:45 +0100)

are available in the Git repository at:

   git://git.pokylinux.org/poky-contrib kangkai/gir
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/gir

Kai Kang (2):
   gobject-introspection: fix multilib install file conflicts
   vala: update vapigen-wrapper


Ping...



  meta/recipes-devtools/vala/vala.inc   |  4 +-
  ...nfigure.ac-make-GIR_DIR-configurable.patch | 65 +++
  .../gobject-introspection_1.58.0.bb   | 10 ++-
  3 files changed, 75 insertions(+), 4 deletions(-)
  create mode 100644 
meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-configure.ac-make-GIR_DIR-configurable.patch



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCHv2] testexport: Add support for testcase utils

[Erik Botö]

Bumping this thread in hope to get some feedback.

Cheers,
Erik

On Tue, Sep 18, 2018 at 11:36 AM Erik Botö  wrote:
>
> Add the possibility to ship a lib/oeqa/runtime/cases/utils directory
> that will be included in the generated testexport tarball.
>
> This makes it easier to split common functionality from test suites
> into modules that can be imported from multiple test suites.
>
> Signed-off-by: Erik Botö 
> ---
>  meta/classes/testexport.bbclass | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/meta/classes/testexport.bbclass b/meta/classes/testexport.bbclass
> index d070f07afa..790ca3aff0 100644
> --- a/meta/classes/testexport.bbclass
> +++ b/meta/classes/testexport.bbclass
> @@ -74,6 +74,21 @@ def testexport_main(d):
>
>  copy_needed_files(d, tc)
>
> +def get_runtime_cases_utils_paths(d):
> +"""
> +Returns a list of paths where testcase utils must reside. Utils can be 
> e.g.
> +common functionality used by multiple test cases.
> +
> +Testcase utils are expected in /lib/oeqa/runtime/cases/utils/
> +"""
> +paths = []
> +
> +for layer in d.getVar('BBLAYERS').split():
> +path = os.path.join(layer, 'lib/oeqa/runtime/cases/utils')
> +if os.path.isdir(path):
> +paths.append(path)
> +return paths
> +
>  def copy_needed_files(d, tc):
>  import shutil
>  import oe.path
> @@ -121,6 +136,14 @@ def copy_needed_files(d, tc):
>  if json_file:
>  shutil.copy2(json_file, cases_path)
>
> +# Copy cases/utils provided by layers
> +utils_dest_path = os.path.join(export_path, 'lib', 'oeqa', 'runtime', 
> 'cases', 'utils')
> +utils_source_paths = get_runtime_cases_utils_paths(d)
> +
> +for f in utils_source_paths:
> +if os.path.isdir(f):
> +oe.path.copytree(f, utils_dest_path)
> +
>  # Copy test data
>  image_name = ("%s/%s" % (d.getVar('DEPLOY_DIR_IMAGE'),
>  d.getVar('IMAGE_LINK_NAME')))
> --
> 2.19.0.rc1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] kernel-devsrc: fix searching for non-existing manifest files

[Andrej Valek]

Even if the do_populate_sysroot have had set-up noexec flag, populate_sdk's
tasks were trying to find .populate_sysroot manifest file. Change noexec
flag settings to delete appreciated task.

WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm allarch 
x86_64_x86_64-nativesdk (variant '')?

WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm allarch 
x86_64_x86_64-nativesdk (variant '')?

Signed-off-by: Andrej Valek 
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 463305e89a..5758572221 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -25,7 +25,7 @@ do_unpack[noexec] = "1"
 do_patch[noexec] = "1"
 do_configure[noexec] = "1"
 do_compile[noexec] = "1"
-do_populate_sysroot[noexec] = "1"
+deltask do_populate_sysroot
 
 S = "${STAGING_KERNEL_DIR}"
 B = "${STAGING_KERNEL_BUILDDIR}"
-- 
2.11.0

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