[PATCH 1/2] meta/conf/layers.conf: Add ca-certificates as ABISAFE

[PATCH 1/2] meta/conf/layers.conf: Add ca-certificates as ABISAFE

[Mark Hatle]

meta-oe was doing this before, but it was triggering a yocto-compat-script
failure during the signature checking.

The ca-certificates changing is ABISAFE, as the certificates themselves do
not modify the compiles behavior of the applications.  This should permit
easier upgrades without as much rebuilding.

The original value was set in meta-oe by commit
ff7a4b13c4efeffc5853a93c6ff7265fa3d6c143.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/layer.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index df457c2..6be2a57 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -40,6 +40,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \
   base-passwd \
   opkg-utils \
   gstreamer1.0-meta-base \
+  ca-certificates \
 "
 
 SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
-- 
1.8.3.1

[PATCH 2/2] bitbake.conf: Add default FILESYSTEM_PERMS_TABLES

[Mark Hatle]

If FILESYSTEM_PERMS_TABLES was not defined, the default was selected by the
packages.bbclass.  This made it difficult for a recipe or layer to 'append'
to the default.

Copy the default into the bitbake.conf, allowing future _append and += style
actions.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/bitbake.conf | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 444c53f..791aee0 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -330,6 +330,10 @@ FILE_DIRNAME = "${@os.path.dirname(d.getVar('FILE', False))}"
 # This default was only used for checking
 FILESEXTRAPATHS ?= "__default:"
 
+# Following is a duplication of the default defined in packages.bbclass,
+# both should be kept in sync
+FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt' if oe.types.boolean(d.getVar('VOLATILE_LOG_DIR', True)) else 'files/fs-perms-persistent-log.txt'}"
+
 ##################################################################
 # General work and output directories for the build system.
 ##################################################################
-- 
1.8.3.1

Re: [PATCH 2/2] bitbake.conf: Add default FILESYSTEM_PERMS_TABLES

[Otavio Salvador]

On Wed, Sep 13, 2017 at 12:15 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> If FILESYSTEM_PERMS_TABLES was not defined, the default was selected by the
> packages.bbclass.  This made it difficult for a recipe or layer to 'append'
> to the default.
>
> Copy the default into the bitbake.conf, allowing future _append and += style
> actions.
>
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>

Couldn't package.bbclass one to be dropped?


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 2/2] bitbake.conf: Add default FILESYSTEM_PERMS_TABLES

[Mark Hatle]

On 9/13/17 12:57 PM, Otavio Salvador wrote:
> On Wed, Sep 13, 2017 at 12:15 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> If FILESYSTEM_PERMS_TABLES was not defined, the default was selected by the
>> packages.bbclass.  This made it difficult for a recipe or layer to 'append'
>> to the default.
>>
>> Copy the default into the bitbake.conf, allowing future _append and += style
>> actions.
>>
>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> 
> Couldn't package.bbclass one to be dropped?
> 
> 

Yes, I didn't do it at present because I was worried it could affect someone and
it's after feature freeze.

If RP is not concerned about this, I can create a V2 that also removes the piece
of package.bbclass.

--Mark

Re: [PATCH 2/2] bitbake.conf: Add default FILESYSTEM_PERMS_TABLES

[Richard Purdie]

On Wed, 2017-09-13 at 13:42 -0500, Mark Hatle wrote:
> On 9/13/17 12:57 PM, Otavio Salvador wrote:
> > 
> > On Wed, Sep 13, 2017 at 12:15 PM, Mark Hatle <mark.hatle@windriver.
> > 
> > Couldn't package.bbclass one to be dropped?
> > 
> > 
> Yes, I didn't do it at present because I was worried it could affect
> someone and
> it's after feature freeze.
> 
> If RP is not concerned about this, I can create a V2 that also
> removes the piece
> of package.bbclass.

I'm ok with this.

Cheers,

Richard