Re: [yocto] how to organize my patches for multiple kernels and multiple target boards?

2016-02-29 Thread Bruce Ashfield 

On 2016-02-29 6:19 PM, Robert P. J. Day wrote:

   (i posted a much lengthier version of this on oe-core recently, but i
want
to cut it down and ask specific questions to clarify what i *think* is
going
on.)

   i want to pull in an existing layer with recipes for linux-4.0.bb and
linux-4.1.bb, and extend them with .bbappend files, to support two
closely-related
machines i'm defining -- call them "mach1" and "mach2". AFAICT, my
patches will
fall somewhere in a 3x3 matrix of possibilities:

   * 3 possibilities of applying against mach1, mach2 or both
   * 3 possibilities of applying against linux-4.0, linux-4.1 or both

so there's my 3x3 matrix.

   the obvious kernel recipe directory structure would be:

   linux/
 linux-4.0.bbappend
 linux-4.1.bbappend
 linux-4.0/[4.0-specific patches]
 linux-4.1/[4.1-specific patches]
 linux/[patches that apply to both]

which suggests that both my .bbappend files would have to contain the line:

   FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:${THISDIR}/${BPN}"

so the SRC_URI search path for linux-4.0.bbappend entries would be
prepended with:

   * linux-4.0/[4.0-specific patches]
   * linux/[patches that apply to both]

and similarly for linux.4.1.bbappend. how am i doing so far? this would
mean that, for each recipe, the more specific directory would be searched
before the general directory. but wait ... there's more.

   now i want to further categorize patches based on exclusive to mach1,
exclusive to mach2, or applicable to both, and since the machine name is
one of the entries in FILESOVERRIDES, i can extend the directory structure
as:

   linux-4.0/
 mach1/
 mach2/
   linux-4.1/
 mach1/
 mach2/
   linux/
 mach1/
 mach2/

and there's my 3x3 matrix of patches, correct? and here's where it gets
unclear.

   i really don't want to have to number all my patches with prefixes like
0001-, 0002- and so on, so what is the ordering of processing for .scc,
.cfg and .patch/.diff files? rather than just lump all the patches into
a single .scc file, i want to refine the patches across multiple .scc
files. is there an imposed order on SRC_URI entries, .scc files and so
on? that's probably all i need to finish this off.


No matter what you method you choose, ordering is as they appear in the
SRC_URI (and normal variable evaluation rules apply)/.

Having maintained more than a few kernel's, my warning is that depending
on your patches, the advantages of mixing version independent patches
with version specific (and board ones) can end up causing a lot of extra
work and maintenance pain. It of course all comes down to what parts of
the kernel they touch, but assuming a normal set of patches you'll find
that you end up tweaking things for order, and then moving patches into
version/board specific places, etc. In particular if you update the base
kernel's to have things like -stable, or other patches that touch lots
of code.

Outside of the kernel version handling (see my warning above), managing
the patches by the SRC_URI works, as would .scc files. Since the entire
point of .scc files is to define a board entry point (the top level .scc
file), and then have it include common patches, configs, etc, all from
that file.

There is another alternative to that management of patches/configs/boards,
and you can create a kernel-cache directory and refer to it on the
SRC_URI. In master, that's how all the boards and patches are managed.

Cheers,

Bruce





rday





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [autobuilder][PATCH] CreateBBLayersConf: optionally exclude repos from default bblayers.conf

2016-02-29 Thread Joe MacDonald 
When a repo is listed in the autobuilder config file, it is automatically
included in the resulting bblayers.conf.  In most scenarios this is the
correct thing to do, however it results in a build error if a layer such
as meta-openembedded is one of the listed repos:

  IOError: [Errno 2] file [...]/build/meta-openembedded/conf/layer.conf not 
found

since meta-openembedded does not contain a top-level conf/ tree and is not
intended to be included as a meta-* layer itself.

Add an 'autoinclude' flag to the 'repo:' stanza of the config file with
the default being 'True' (ie. the current behaviour) but when set to
'False' the layer will still be checked out (making this behaviour
distinct from the 'checkout' flag) but not included in the bblayer.conf by
default, only layers specifically referenced in the CreateBBLayersConf
section of the 'steps:' stanza will be included.

Signed-off-by: Joe MacDonald 
---
 .../site-packages/autobuilder/buildsteps/CreateBBLayersConf.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py
index 03cb2a1..ace9fbb 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py
@@ -95,7 +95,8 @@ class CreateBBLayersConf(ShellCommand):
 elif layer.iterkeys().next()=="meta-qt4":
 if layerversioncore is not None and 
int(layerversioncore) > 6:
 fout = fout + workdir + '/build/' + 
layer.iterkeys().next() + ' \ \n'
-else:
+elif 
(layer[layer.iterkeys().next()].has_key('autoinclude') and 
layer[layer.iterkeys().next()]['autoinclude'] is not False) or \
+ 
layer[layer.iterkeys().next()].has_key('autoinclude') is False:
 fout = fout + workdir + '/build/' + 
layer.iterkeys().next() + ' \ \n'
 ldirs.append(layer.iterkeys().next())
 
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][autobuilder] lib/buildsteps.py: Add BitbakeShellCommand class for dump bitbake logs

2016-02-29 Thread Aníbal Limón 
The BitbakeShellCommand is a new class for store common methods when
is aim to run bitbake inside an step.

This commit overrides commandComplete method for search in bitbake
stdout if ERROR exists and if found then open the bitbake log and
dumps into new bitbake_logs output.

Signed-off-by: Aníbal Limón 
---
 .../autobuilder/buildsteps/BuildImages.py  |  4 +++-
 .../autobuilder/buildsteps/BuildToolchainImages.py |  4 +++-
 .../autobuilder/buildsteps/GetBitbakeVersion.py|  4 +++-
 .../autobuilder/buildsteps/RunESDKSanityTests.py   |  4 +++-
 .../autobuilder/buildsteps/RunSDKSanityTests.py|  4 +++-
 .../autobuilder/buildsteps/RunSanityTests.py   |  4 +++-
 .../site-packages/autobuilder/lib/buildsteps.py| 28 ++
 7 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
index 4987ef3..5ed6e1a 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
@@ -17,7 +17,9 @@ from distutils.version import StrictVersion
 from buildbot.status.results import SUCCESS
 import os
 
-class BuildImages(ShellCommand):
+from lib.buildsteps import BitbakeShellCommand
+
+class BuildImages(BitbakeShellCommand):
 haltOnFailure = False
 flunkOnFailure = True
 name = "BuildImages"
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildToolchainImages.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildToolchainImages.py
index 51069c2..0594ac2 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildToolchainImages.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildToolchainImages.py
@@ -15,7 +15,9 @@ from buildbot.steps.shell import ShellCommand
 from buildbot.process.buildstep import LogLineObserver
 import os
 
-class BuildToolchainImages(ShellCommand):
+from lib.buildsteps import BitbakeShellCommand
+
+class BuildToolchainImages(BitbakeShellCommand):
 haltOnFailure = False
 flunkOnFailure = True
 name = "Building Toolchain Images"
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py
index dc6c25b..94b5efe 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py
@@ -16,7 +16,9 @@ from buildbot.process.properties import WithProperties
 from twisted.python import log
 from autobuilder.config import *
 
-class GetBitbakeVersion(ShellCommand):
+from lib.buildsteps import BitbakeShellCommand
+
+class GetBitbakeVersion(BitbakeShellCommand):
 haltOnFailure = False
 flunkOnFailure = False
 name = "GetBitbakeVersion"
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py
index e3df6c8..f2817d4 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py
@@ -16,7 +16,9 @@ from buildbot.status.results import SUCCESS, FAILURE
 from twisted.python import log as tlog
 import os, re
 
-class RunESDKSanityTests(ShellCommand):
+from lib.buildsteps import BitbakeShellCommand
+
+class RunESDKSanityTests(BitbakeShellCommand):
 
 haltOnFailure = False
 flunkOnFailure = True
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py
index cc0321f..1eeb4d3 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py
@@ -16,7 +16,9 @@ from buildbot.status.results import SUCCESS, FAILURE
 from twisted.python import log as tlog
 import os, re
 
-class RunSDKSanityTests(ShellCommand):
+from lib.buildsteps import BitbakeShellCommand
+
+class RunSDKSanityTests(BitbakeShellCommand):
 
 haltOnFailure = False
 flunkOnFailure = True
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
index 62f04af..15a714c 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
@@ -16,7 +16,9 @@ from buildbot.status.results import SUCCESS, FAILURE
 from twisted.python import log as tlog
 import os, re
 
-class RunSanityTests(ShellCommand):
+from lib.buildsteps import BitbakeShellCommand
+
+class RunSanityTests(BitbakeShellCommand):
 
 haltOnFailure = False
 flunkOnFailure = True
diff --git a/lib/python2.7/site-packages/autobuilder/lib/buildsteps.py 
b/lib/python2.7/site-packages/au

Re: [yocto] how to organize my patches for multiple kernels and multiple target boards?

2016-02-29 Thread Andrea Adami 
On Tue, Mar 1, 2016 at 12:19 AM, Robert P. J. Day  wrote:
>   (i posted a much lengthier version of this on oe-core recently, but i want
> to cut it down and ask specific questions to clarify what i *think* is going
> on.)
>
>   i want to pull in an existing layer with recipes for linux-4.0.bb and
> linux-4.1.bb, and extend them with .bbappend files, to support two
> closely-related
> machines i'm defining -- call them "mach1" and "mach2". AFAICT, my patches
> will
> fall somewhere in a 3x3 matrix of possibilities:
>
>   * 3 possibilities of applying against mach1, mach2 or both
>   * 3 possibilities of applying against linux-4.0, linux-4.1 or both
>
> so there's my 3x3 matrix.
>
>   the obvious kernel recipe directory structure would be:
>
>   linux/
> linux-4.0.bbappend
> linux-4.1.bbappend
> linux-4.0/[4.0-specific patches]
> linux-4.1/[4.1-specific patches]
> linux/[patches that apply to both]
>
> which suggests that both my .bbappend files would have to contain the line:
>
>   FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:${THISDIR}/${BPN}"
>
> so the SRC_URI search path for linux-4.0.bbappend entries would be
> prepended with:
>
>   * linux-4.0/[4.0-specific patches]
>   * linux/[patches that apply to both]
>
> and similarly for linux.4.1.bbappend. how am i doing so far? this would
> mean that, for each recipe, the more specific directory would be searched
> before the general directory. but wait ... there's more.
>
>   now i want to further categorize patches based on exclusive to mach1,
> exclusive to mach2, or applicable to both, and since the machine name is
> one of the entries in FILESOVERRIDES, i can extend the directory structure
> as:
>
>   linux-4.0/
> mach1/
> mach2/
>   linux-4.1/
> mach1/
> mach2/
>   linux/
> mach1/
> mach2/
>
> and there's my 3x3 matrix of patches, correct? and here's where it gets
> unclear.
>
>   i really don't want to have to number all my patches with prefixes like
> 0001-, 0002- and so on, so what is the ordering of processing for .scc,
> .cfg and .patch/.diff files? rather than just lump all the patches into
> a single .scc file, i want to refine the patches across multiple .scc
> files. is there an imposed order on SRC_URI entries, .scc files and so
> on? that's probably all i need to finish this off.
>
> rday

Robert,

in the past I have done pretty much the same: scc,cfg and patches all
packed in the recipe.
Please see these (outdated) layout examples for linux-yocto* that were
in meta-handheld.

for 3.10, using .cfg & .scc
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux?h=dylan

Or simplified, for 3.14, using defconfig, with patches listed in SRC_URI
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux?h=dizzy

Regards

Andrea

>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how to organize my patches for multiple kernels and multiple target boards?

2016-02-29 Thread Robert P. J. Day 

  (i posted a much lengthier version of this on oe-core recently, but i want
to cut it down and ask specific questions to clarify what i *think* is going
on.)

  i want to pull in an existing layer with recipes for linux-4.0.bb  
and linux-4.1.bb, and extend them with .bbappend files, to support two  
closely-related
machines i'm defining -- call them "mach1" and "mach2". AFAICT, my  
patches will

fall somewhere in a 3x3 matrix of possibilities:

  * 3 possibilities of applying against mach1, mach2 or both
  * 3 possibilities of applying against linux-4.0, linux-4.1 or both

so there's my 3x3 matrix.

  the obvious kernel recipe directory structure would be:

  linux/
linux-4.0.bbappend
linux-4.1.bbappend
linux-4.0/[4.0-specific patches]
linux-4.1/[4.1-specific patches]
linux/[patches that apply to both]

which suggests that both my .bbappend files would have to contain the line:

  FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:${THISDIR}/${BPN}"

so the SRC_URI search path for linux-4.0.bbappend entries would be
prepended with:

  * linux-4.0/[4.0-specific patches]
  * linux/[patches that apply to both]

and similarly for linux.4.1.bbappend. how am i doing so far? this would
mean that, for each recipe, the more specific directory would be searched
before the general directory. but wait ... there's more.

  now i want to further categorize patches based on exclusive to mach1,
exclusive to mach2, or applicable to both, and since the machine name is
one of the entries in FILESOVERRIDES, i can extend the directory structure
as:

  linux-4.0/
mach1/
mach2/
  linux-4.1/
mach1/
mach2/
  linux/
mach1/
mach2/

and there's my 3x3 matrix of patches, correct? and here's where it gets
unclear.

  i really don't want to have to number all my patches with prefixes like
0001-, 0002- and so on, so what is the ordering of processing for .scc,
.cfg and .patch/.diff files? rather than just lump all the patches into
a single .scc file, i want to refine the patches across multiple .scc
files. is there an imposed order on SRC_URI entries, .scc files and so
on? that's probably all i need to finish this off.

rday



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] audit: upgrade 2.4.4 -> 2.5

2016-02-29 Thread T.O. Radzy Radzykewycz 
* rebase patch audit-python-configure.patch

* remove audit-auvirt-get-inline-functions-work-with-gnu89-gnu11.patch
  as it had already been applied upstream

* 2.5 includes miscellaneous enhancements and fixes:

2.5
- Make augenrules the default method to load audit rules
- Put rules in its own directory and break out rules into groups
- Have auditd do a fsync before closing log
- Make default flush setting larger
- In auparse. terminate the generated strings (Burn Alting)
- In auditd, add incremental_async flushing mode
- Clean up dangling fields in DAEMON events
- Add audit by process name support to auditctl (Richard Briggs)
- Relax permissions on systemd files
- Fix auparse to handle interlaced events (Burn Alting)
- Allow more syslog facilities in audispd-syslog (Aleksander Adamowski)

2.4.5
- Fix auditd disk flushing for data and sync modes
- Fix auditctl to not show options not supported on older OS
- Add audit.m4 file to aid adding support to other projects
- Fix C99 inline function build issue
- Add account lock and unlock event types
- Change logging loophole check to geteuid()
- Fix ausearch to not consider AUDIT_PROCTITLE events malformed (Burn Alting)
- Fix ausearch to parse FEATURE_CHANGE events

( From http://people.redhat.com/sgrubb/audit/ChangeLog )

Signed-off-by: T.O. Radzy Radzykewycz 
---
 ...et-inline-functions-work-with-gnu89-gnu11.patch |  71 --
 .../audit/audit/audit-python-configure.patch   |   3 +-
 recipes-security/audit/audit_2.4.4.bb  | 100 
 recipes-security/audit/audit_2.5.bb| 104 +
 4 files changed, 106 insertions(+), 172 deletions(-)
 delete mode 100644 
recipes-security/audit/audit/audit-auvirt-get-inline-functions-work-with-gnu89-gnu11.patch
 delete mode 100644 recipes-security/audit/audit_2.4.4.bb
 create mode 100644 recipes-security/audit/audit_2.5.bb

diff --git 
a/recipes-security/audit/audit/audit-auvirt-get-inline-functions-work-with-gnu89-gnu11.patch
 
b/recipes-security/audit/audit/audit-auvirt-get-inline-functions-work-with-gnu89-gnu11.patch
deleted file mode 100644
index 578cfc1dc476..
--- 
a/recipes-security/audit/audit/audit-auvirt-get-inline-functions-work-with-gnu89-gnu11.patch
+++ /dev/null
@@ -1,71 +0,0 @@
-From 15036dd4fa9eb209f5e148c6f7ee081f5ca78fa4 Mon Sep 17 00:00:00 2001
-From: Wenzong Fan 
-Date: Fri, 11 Sep 2015 03:37:13 -0400
-Subject: [PATCH] audit/auvirt: get inline functions work with both gnu89 & 
gnu11
-
-After gcc upgraded to gcc5, and if the codes are compiled without
-optimization (-O0), and the below error will happen:
-
-  auvirt.c:484: undefined reference to `copy_str'
-  auvirt.c:667: undefined reference to `is_resource'
-  collect2: error: ld returned 1 exit status
-
-gcc5 defaults to -std=gnu11 instead of -std=gnu89, and it requires that
-exactly one C source file has the callable copy of the inline function.
-Consider the following program:
-
-  inline int
-  foo (void)
-  {
-return 42;
-  }
-
-  int
-  main (void)
-  {
-return foo ();
-  }
-
-The program above will not link with the C99 inline semantics, because
-no out-of-line function foo is generated. To fix this, either mark the
-function foo as static, or add the following declaration:
-
-  static inline int foo (void);
-
-More information refer to: https://gcc.gnu.org/gcc-5/porting_to.html
-
-Note: using "extern inline" will fail to build with gcc4.x, so replace
-inline with "static inline".
-
-Upstream-Status: Pending
-
-Signed-off-by: Wenzong Fan 

- tools/auvirt/auvirt.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/tools/auvirt/auvirt.c b/tools/auvirt/auvirt.c
-index 655c454..b16d718 100644
 a/tools/auvirt/auvirt.c
-+++ b/tools/auvirt/auvirt.c
-@@ -138,7 +138,7 @@ void event_free(struct event *event)
-   }
- }
- 
--inline char *copy_str(const char *str)
-+static inline char *copy_str(const char *str)
- {
-   return (str) ? strdup(str) : NULL;
- }
-@@ -650,7 +650,7 @@ int process_control_event(auparse_state_t *au)
-   return 0;
- }
- 
--inline int is_resource(const char *res)
-+static inline int is_resource(const char *res)
- {
-   if (res == NULL ||
-   res[0] == '\0' ||
--- 
-1.9.1
-
diff --git a/recipes-security/audit/audit/audit-python-configure.patch 
b/recipes-security/audit/audit/audit-python-configure.patch
index b47cf5d2d968..cb62ec3022bb 100644
--- a/recipes-security/audit/audit/audit-python-configure.patch
+++ b/recipes-security/audit/audit/audit-python-configure.patch
@@ -8,6 +8,7 @@ Upstream-Status: pending
 Signed-off-by: Xin Ouyang 
 Signed-off-by: Li Xin 
 Signed-off-by: Wenzong Fan 
+Signed-off-by: T.O. Radzy Radzykewycz 
 ---
  configure.ac | 17 ++---
  1 file changed, 2 insertions(+), 15 deletions(-)
@@ -29,7 +30,7 @@ index 1f48cb4..cdb5219 100644
 -  AC_MSG_NOTICE(Python bindings will be built)
 -else
 -  python_found="no"
--  if test x$use_python = xyes ; then
+-

[yocto] [meta-selinux][PATCH] at: drop obsolete SELinux patch

2016-02-29 Thread Stephen Smalley 
SELinux support was merged upstream in at-3.1.18,
so this patch no longer applies and is not needed.

Signed-off-by: Stephen Smalley 
---
 recipes-extended/at/at/at-3.1.13-selinux.patch | 184 -
 recipes-extended/at/at_%.bbappend  |   6 -
 2 files changed, 190 deletions(-)
 delete mode 100644 recipes-extended/at/at/at-3.1.13-selinux.patch

diff --git a/recipes-extended/at/at/at-3.1.13-selinux.patch 
b/recipes-extended/at/at/at-3.1.13-selinux.patch
deleted file mode 100644
index 4e5e18c..000
--- a/recipes-extended/at/at/at-3.1.13-selinux.patch
+++ /dev/null
@@ -1,184 +0,0 @@
-From: Xin Ouyang 
-Date: Wed, 13 Jun 2012 14:47:54 +0800
-Subject: [PATCH] at: atd add SELinux support.
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Xin Ouyang 

- Makefile.in  |1 +
- atd.c|   83 ++
- config.h.in  |3 ++
- configure.ac |8 +
- 4 files changed, 95 insertions(+), 0 deletions(-)
-
-diff --git a/Makefile.in b/Makefile.in
-index 10e7ed2..35792cd 100644
 a/Makefile.in
-+++ b/Makefile.in
-@@ -39,6 +39,7 @@ LIBS = @LIBS@
- LIBOBJS   = @LIBOBJS@
- INSTALL   = @INSTALL@
- PAMLIB  = @PAMLIB@
-+SELINUXLIB  = @SELINUXLIB@
- 
- CLONES= atq atrm
- ATOBJECTS = at.o panic.o perm.o posixtm.o y.tab.o lex.yy.o
-@@ -72,7 +72,7 @@ at: $(ATOBJECTS)
-   $(LN_S) -f at atrm
- 
- atd: $(RUNOBJECTS)
--  $(CC) $(LDFLAGS) -o atd $(RUNOBJECTS) $(LIBS) $(PAMLIB)
-+  $(CC) $(LDFLAGS) -o atd $(RUNOBJECTS) $(LIBS) $(PAMLIB) $(SELINUXLIB)
- 
- y.tab.c y.tab.h: parsetime.y
-   $(YACC) -d parsetime.y
-diff --git a/atd.c b/atd.c
-index af3e577..463124f 100644
 a/atd.c
-+++ b/atd.c
-@@ -83,6 +83,14 @@
- #include "getloadavg.h"
- #endif
- 
-+#ifdef WITH_SELINUX
-+#include 
-+#include 
-+int selinux_enabled = 0;
-+#include 
-+#include 
-+#endif
-+
- /* Macros */
- 
- #define BATCH_INTERVAL_DEFAULT 60
-@@ -195,6 +203,70 @@ myfork()
- #define fork myfork
- #endif
- 
-+#ifdef WITH_SELINUX
-+static int
-+set_selinux_context(const char *name, const char *filename)
-+{
-+security_context_t user_context=NULL;
-+security_context_t  file_context=NULL;
-+struct av_decision avd;
-+int retval=-1;
-+char *seuser=NULL;
-+char *level=NULL;
-+
-+if (getseuserbyname(name, &seuser, &level) == 0) {
-+  retval=get_default_context_with_level(seuser, level, NULL, 
&user_context);
-+  free(seuser);
-+  free(level);
-+  if (retval) {
-+  if (security_getenforce()==1) {
-+  perr("execle: couldn't get security context for user %s\n", 
name);
-+  } else {
-+  syslog(LOG_ERR, "execle: couldn't get security context for user 
%s\n", name);
-+  return -1;
-+  }
-+  }
-+}
-+
-+/*
-+* Since crontab files are not directly executed,
-+* crond must ensure that the crontab file has
-+* a context that is appropriate for the context of
-+* the user cron job.  It performs an entrypoint
-+* permission check for this purpose.
-+*/
-+if (fgetfilecon(STDIN_FILENO, &file_context) < 0)
-+  perr("fgetfilecon FAILED %s", filename);
-+
-+retval = security_compute_av(user_context,
-+  file_context,
-+  SECCLASS_FILE,
-+  FILE__ENTRYPOINT,
-+  &avd);
-+freecon(file_context);
-+if (retval || ((FILE__ENTRYPOINT & avd.allowed) != FILE__ENTRYPOINT)) {
-+  if (security_getenforce()==1) {
-+  perr("Not allowed to set exec context to %s for user  %s\n", 
user_context,name);
-+  } else {
-+  syslog(LOG_ERR, "Not allowed to set exec context to %s for user  
%s\n", user_context,name);
-+  retval = -1;
-+  goto err;
-+  }
-+}
-+if (setexeccon(user_context) < 0) {
-+  if (security_getenforce()==1) {
-+  perr("Could not set exec context to %s for user  %s\n", 
user_context,name);
-+  retval = -1;
-+  } else {
-+  syslog(LOG_ERR, "Could not set exec context to %s for user  %s\n", 
user_context,name);
-+  }
-+}
-+err:
-+freecon(user_context);
-+return 0;
-+}
-+#endif
-+
- static void
- run_file(const char *filename, uid_t uid, gid_t gid)
- {
-@@ -435,6 +507,13 @@ run_file(const char *filename, uid_t uid, gid_t gid)
- 
-   chdir("/");
- 
-+#ifdef WITH_SELINUX
-+  if (selinux_enabled > 0) {
-+  if (set_selinux_context(pentry->pw_name, filename) < 0)
-+  perr("SELinux Failed to set context\n");
-+  }
-+#endif
-+
-   if (execle("/bin/sh", "sh", (char *) NULL, nenvp) != 0)
-   perr("Exec failed for /bin/sh");
- 
-@@ -707,6 +786,10 @@ main(int argc, char *argv[])
- struct passwd *pwe;
- struct group *ge;
- 
-+#ifdef WITH_SELINUX
-+selinux_enabled = is_selinux_enabled();
-+#endif
-+
- /*

Re: [yocto] [meta-raspberrypi][PATCH v3 2/6] .gitignore: Ignore .swp files

2016-02-29 Thread Andrei Gherzan 
On Sun, Feb 28, 2016 at 02:46:09PM +0100, Petter Mabäcker wrote:
> Signed-off-by: Petter Mabäcker 
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 1677b58..f235765 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,2 +1,3 @@
>  build*
>  *~
> +.*.swp

Merged to master. Thanks.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 1/1] omxplayer: Add patch to fix host-user-contaminated QA

2016-02-29 Thread Andrei Gherzan 
On Sun, Feb 28, 2016 at 11:32:53AM +0100, Andrei Gherzan wrote:
> Signed-off-by: Andrei Gherzan 
> Signed-off-by: Jonathan Liu 
> ---
>  .../don-t-preserve-file-attributes-when-cp.patch   | 18 
> ++
>  recipes-multimedia/omxplayer/omxplayer_git.bb  |  1 +
>  2 files changed, 19 insertions(+)
>  create mode 100644 
> recipes-multimedia/omxplayer/omxplayer/don-t-preserve-file-attributes-when-cp.patch
>
> diff --git 
> a/recipes-multimedia/omxplayer/omxplayer/don-t-preserve-file-attributes-when-cp.patch
>  
> b/recipes-multimedia/omxplayer/omxplayer/don-t-preserve-file-attributes-when-cp.patch
> new file mode 100644
> index 000..08df12e
> --- /dev/null
> +++ 
> b/recipes-multimedia/omxplayer/omxplayer/don-t-preserve-file-attributes-when-cp.patch
> @@ -0,0 +1,18 @@
> +When running install (fakeroot) host-user-contaminated will fail because dist
> +rule copies files while preserving file attributes like user ID.
> +
> +Upstream-Status: Submitted [https://github.com/popcornmix/omxplayer/pull/431]
> +Signed-off-by: Andrei Gherzan 
> +
> +Index: git/Makefile
> +===
> +--- git.orig/Makefile
>  git/Makefile
> +@@ -87,5 +87,5 @@ dist: omxplayer.bin omxplayer.1
> + cp COPYING $(DIST)/usr/share/doc/omxplayer
> + cp README.md $(DIST)/usr/share/doc/omxplayer/README
> + cp omxplayer.1 $(DIST)/usr/share/man/man1
> +-cp -a ffmpeg_compiled/usr/lib/*.so* $(DIST)/usr/lib/omxplayer/
> ++cp -P ffmpeg_compiled/usr/lib/*.so* $(DIST)/usr/lib/omxplayer/
> + tar -czf omxplayer-dist.tar.gz $(DIST)
> +\ No newline at end of file
> diff --git a/recipes-multimedia/omxplayer/omxplayer_git.bb 
> b/recipes-multimedia/omxplayer/omxplayer_git.bb
> index a0690a0..c8251fe 100644
> --- a/recipes-multimedia/omxplayer/omxplayer_git.bb
> +++ b/recipes-multimedia/omxplayer/omxplayer_git.bb
> @@ -18,6 +18,7 @@ SRC_URI = 
> "git://github.com/popcornmix/omxplayer.git;protocol=git;branch=master
> 
> file://0004-Add-FFMPEG_EXTRA_CFLAGS-and-FFMPEG_EXTRA_LDFLAGS.patch \
> file://fix-tar-command-with-DIST.patch \
> file://use-native-pkg-config.patch \
> +   file://don-t-preserve-file-attributes-when-cp.patch \
> "
>  S = "${WORKDIR}/git"
>

Merged to master. Thank you.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 10/23] rpio: Include sys/types.h for caddr_t

2016-02-29 Thread Andrei Gherzan 
On Sat, Feb 27, 2016 at 03:26:49PM +, Khem Raj wrote:
> Fixes build with musl
>
> Signed-off-by: Khem Raj 
> ---
>  ...-types.h-explicitly-for-getting-caddr_t-d.patch | 30 
> ++
>  recipes-devtools/python/rpio_0.10.0.bb |  6 ++---
>  2 files changed, 33 insertions(+), 3 deletions(-)
>  create mode 100644 
> recipes-devtools/python/rpio/0001-include-sys-types.h-explicitly-for-getting-caddr_t-d.patch
>
> diff --git 
> a/recipes-devtools/python/rpio/0001-include-sys-types.h-explicitly-for-getting-caddr_t-d.patch
>  
> b/recipes-devtools/python/rpio/0001-include-sys-types.h-explicitly-for-getting-caddr_t-d.patch
> new file mode 100644
> index 000..bed9749
> --- /dev/null
> +++ 
> b/recipes-devtools/python/rpio/0001-include-sys-types.h-explicitly-for-getting-caddr_t-d.patch
> @@ -0,0 +1,30 @@
> +From c86bfacc98d58244f532626954ed00d84ecfa82d Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sat, 30 Jan 2016 17:12:37 -0800
> +Subject: [PATCH] include sys/types.h explicitly for getting caddr_t 
> definition
> +
> +Helps fixing build on musl where sys/types.h is not included indirectly
> +as happening on glibc
> +
> +Signed-off-by: Khem Raj 
> +---
> +Upstream-Status: Submitted
> +
> + source/c_gpio/c_gpio.c | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/source/c_gpio/c_gpio.c b/source/c_gpio/c_gpio.c
> +index 25a04ca..70df632 100644
> +--- a/source/c_gpio/c_gpio.c
>  b/source/c_gpio/c_gpio.c
> +@@ -29,6 +29,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + #include 
> + #include "c_gpio.h"
> +
> +--
> +2.7.0
> +
> diff --git a/recipes-devtools/python/rpio_0.10.0.bb 
> b/recipes-devtools/python/rpio_0.10.0.bb
> index 1cc1661..69ecb6f 100644
> --- a/recipes-devtools/python/rpio_0.10.0.bb
> +++ b/recipes-devtools/python/rpio_0.10.0.bb
> @@ -7,9 +7,9 @@ LIC_FILES_CHKSUM = 
> "file://README.rst;beginline=41;endline=53;md5=d5d95d7486a4d9
>
>  SRCNAME = "RPIO"
>
> -SRC_URI = "\
> -  
> http://pypi.python.org/packages/source/R/RPIO/${SRCNAME}-${PV}.tar.gz \
> -  "
> +SRC_URI = 
> "http://pypi.python.org/packages/source/R/RPIO/${SRCNAME}-${PV}.tar.gz \
> +   
> file://0001-include-sys-types.h-explicitly-for-getting-caddr_t-d.patch \
> +   "
>  S = "${WORKDIR}/${SRCNAME}-${PV}"
>
>  inherit setuptools

Merged to master. Thank you.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 07/23] python-rtimu: Fix build with musl

2016-02-29 Thread Andrei Gherzan 
On Sat, Feb 27, 2016 at 03:26:46PM +, Khem Raj wrote:
> ioctl(3) needs to include asm/ioctl.h for its signature
>
> Signed-off-by: Khem Raj 
> ---
>  ...0001-include-asm-ioctl.h-for-ioctl-define.patch | 33 
> ++
>  recipes-devtools/python/python-rtimu_git.bb|  4 ++-
>  2 files changed, 36 insertions(+), 1 deletion(-)
>  create mode 100644 
> recipes-devtools/python/python-rtimu/0001-include-asm-ioctl.h-for-ioctl-define.patch
>
> diff --git 
> a/recipes-devtools/python/python-rtimu/0001-include-asm-ioctl.h-for-ioctl-define.patch
>  
> b/recipes-devtools/python/python-rtimu/0001-include-asm-ioctl.h-for-ioctl-define.patch
> new file mode 100644
> index 000..4a93a1c
> --- /dev/null
> +++ 
> b/recipes-devtools/python/python-rtimu/0001-include-asm-ioctl.h-for-ioctl-define.patch
> @@ -0,0 +1,33 @@
> +From c3aa4af56652b403e304ea5f321acfe289e42922 Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sat, 30 Jan 2016 16:07:14 -0800
> +Subject: [PATCH] include asm/ioctl.h for ioctl() define
> +
> +also fixes errors e.g.
> +
> +../../RTIMULib/RTIMUHal.cpp:208:29: error: '_IOC_SIZEBITS' was not
> +declared in this scope
> + return ioctl(m_SPI, SPI_IOC_MESSAGE(1), &wrIOC);
> +
> +Signed-off-by: Khem Raj 
> +---
> +Upstream-Status: Submitted
> +
> + RTIMULib/RTIMUHal.cpp | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/RTIMULib/RTIMUHal.cpp b/RTIMULib/RTIMUHal.cpp
> +index f9c3d15..d968326 100644
> +--- a/RTIMULib/RTIMUHal.cpp
>  b/RTIMULib/RTIMUHal.cpp
> +@@ -29,6 +29,7 @@
> + #if !defined(WIN32) && !defined(__APPLE__)
> +
> + #include 
> ++#include 
> +
> + RTIMUHal::RTIMUHal()
> + {
> +--
> +2.7.0
> +
> diff --git a/recipes-devtools/python/python-rtimu_git.bb 
> b/recipes-devtools/python/python-rtimu_git.bb
> index f51a234..63c92b3 100644
> --- a/recipes-devtools/python/python-rtimu_git.bb
> +++ b/recipes-devtools/python/python-rtimu_git.bb
> @@ -5,7 +5,9 @@ SECTION = "devel/python"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = 
> "file://../../LICENSE;md5=96cdecb41125f498958e09b72faf318e"
>
> -SRC_URI = 
> "git://github.com/RPi-Distro/RTIMULib.git;protocol=http;branch=master"
> +SRC_URI = 
> "git://github.com/RPi-Distro/RTIMULib.git;protocol=http;branch=master \
> +   
> file://0001-include-asm-ioctl.h-for-ioctl-define.patch;patchdir=../.. \
> +  "
>  SRCREV = "b949681af69b45f0f7f4bb53b6770037b5b02178"
>
>  S = "${WORKDIR}/git/Linux/python/"

Hi Raj! Merged to master. Thank you.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 08/23] wiringPi: Fix build with musl

2016-02-29 Thread Andrei Gherzan 
On Sat, Feb 27, 2016 at 03:26:47PM +, Khem Raj wrote:
> Include asm/ioctl.h for _IOC_SIZEBITS
>
> Signed-off-by: Khem Raj 
> ---
>  ...de-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch | 58 
> ++
>  recipes-devtools/wiringPi/wiringpi_git.bb  |  8 +--
>  2 files changed, 62 insertions(+), 4 deletions(-)
>  create mode 100644 
> recipes-devtools/wiringPi/wiringpi/0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch
>
> diff --git 
> a/recipes-devtools/wiringPi/wiringpi/0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch
>  
> b/recipes-devtools/wiringPi/wiringpi/0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch
> new file mode 100644
> index 000..5de5853
> --- /dev/null
> +++ 
> b/recipes-devtools/wiringPi/wiringpi/0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch
> @@ -0,0 +1,58 @@
> +From 7f65eb37a82a6d9b095d9c8f262ad9dd205acd03 Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sat, 30 Jan 2016 16:57:38 -0800
> +Subject: [PATCH] include  directly for _IOC_SIZEBITS
> +
> +Fixes errors like
> +| wiringPiSPI.c: In function 'wiringPiSPIDataRW':
> +| wiringPiSPI.c:89:35: error: '_IOC_SIZEBITS' undeclared (first use in
> +this function)
> +
> +Signed-off-by: Khem Raj 
> +---
> +Upstream-Status: Submitted
> +
> + wiringPi/wiringPi.c| 1 +
> + wiringPi/wiringPiI2C.c | 1 +
> + wiringPi/wiringPiSPI.c | 1 +
> + 3 files changed, 3 insertions(+)
> +
> +diff --git a/wiringPi/wiringPi.c b/wiringPi/wiringPi.c
> +index 32e5100..cb5db9d 100644
> +--- a/wiringPi/wiringPi.c
>  b/wiringPi/wiringPi.c
> +@@ -64,6 +64,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + #include 
> + #include 
> + #include 
> +diff --git a/wiringPi/wiringPiI2C.c b/wiringPi/wiringPiI2C.c
> +index c787bce..efdf53c 100644
> +--- a/wiringPi/wiringPiI2C.c
>  b/wiringPi/wiringPiI2C.c
> +@@ -52,6 +52,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> +
> + #include "wiringPi.h"
> + #include "wiringPiI2C.h"
> +diff --git a/wiringPi/wiringPiSPI.c b/wiringPi/wiringPiSPI.c
> +index 453df31..ae3c7d9 100644
> +--- a/wiringPi/wiringPiSPI.c
>  b/wiringPi/wiringPiSPI.c
> +@@ -27,6 +27,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + #include 
> + #include 
> +
> +--
> +2.7.0
> +
> diff --git a/recipes-devtools/wiringPi/wiringpi_git.bb 
> b/recipes-devtools/wiringPi/wiringpi_git.bb
> index 4254a0a..9d2206b 100644
> --- a/recipes-devtools/wiringPi/wiringpi_git.bb
> +++ b/recipes-devtools/wiringPi/wiringpi_git.bb
> @@ -9,10 +9,10 @@ SRCREV = "d79506694d7ba1c3da865d095238289d6175057d"
>
>  S = "${WORKDIR}/git"
>
> -SRC_URI = "\
> -  git://git.drogon.net/wiringPi \
> -  file://0001-Add-initial-cross-compile-support.patch \
> -  "
> +SRC_URI = "git://git.drogon.net/wiringPi \
> +   file://0001-Add-initial-cross-compile-support.patch \
> +   file://0001-include-asm-ioctl.h-directly-for-_IOC_SIZEBITS.patch \
> +   "
>
>  COMPATIBLE_MACHINE = "raspberrypi"
>

Hi Raj! Merged to master. Thank you.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 19/23] rpi-config: Upgrade to tip of tree to get GPU_MEM_1024

2016-02-29 Thread Andrei Gherzan 
On Sat, Feb 27, 2016 at 03:26:58PM +, Khem Raj wrote:
> Document it in README
>
> Signed-off-by: Khem Raj 
> ---
>  README  | 2 ++
>  recipes-bsp/bootfiles/rpi-config_git.bb | 5 -
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/README b/README
> index 16ac1cb..efe885b 100644
> --- a/README
> +++ b/README
> @@ -90,6 +90,8 @@ GPU_MEM_256 : GPU memory in megabyte for the 256MB 
> Raspberry Pi. Ignored by the
>512MB RP. Overrides gpu_mem. Max 192. Default not set.
>  GPU_MEM_512 : GPU memory in megabyte for the 512MB Raspberry Pi. Ignored by 
> the
>256MB RP. Overrides gpu_mem. Max 448. Default not set.
> +GPU_MEM_1024: GPU memory in megabyte for the 1024MB Raspberry Pi. Ignored by 
> the
> +  256MB/512MB RP. Overrides gpu_mem. Max 944. Default not set.
>
>  2.C.Optional - Add purchased license codecs:
>  
> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb 
> b/recipes-bsp/bootfiles/rpi-config_git.bb
> index aa11b25..4cdffca 100644
> --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384
>
>  COMPATIBLE_MACHINE = "raspberrypi"
>
> -SRCREV = "5d2ca5f9bcb1b239c051e20c05a233fd79cf09d5"
> +SRCREV = "648ffc470824c43eb0d16c485f4c24816b32cd6f"
>  SRC_URI = 
> "git://github.com/Evilpaul/RPi-config.git;protocol=git;branch=master \
>"
>
> @@ -54,6 +54,9 @@ do_deploy() {
>  if [ -n "${GPU_MEM_512}" ]; then
>  sed -i '/#gpu_mem_512/ c\gpu_mem_512=${GPU_MEM_512}' 
> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
>  fi
> +if [ -n "${GPU_MEM_1024}" ]; then
> +sed -i '/#gpu_mem_1024/ c\gpu_mem_1024=${GPU_MEM_1024}' 
> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +fi
>
>  # Video camera support
>  if [ -n "${VIDEO_CAMERA}" ]; then

Hi Raj,

Merged to master. Thank you.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 17/23] linux-raspberrypi: Upgrade 4.1 kernel to 4.1.17

2016-02-29 Thread Andrei Gherzan 
On Sat, Feb 27, 2016 at 03:26:56PM +, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> ---
>  recipes-kernel/linux/linux-raspberrypi_4.1.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.1.bb 
> b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
> index 3a3cf40..d5bfa45 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.1.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
> @@ -1,6 +1,6 @@
> -LINUX_VERSION ?= "4.1.10"
> +LINUX_VERSION ?= "4.1.17"
>
> -SRCREV = "b74df9228c27f55361c065bc5dbfba88861cc771"
> +SRCREV = "cb2f10196a9b718a2d94bb4ac0887c2ea14988ae"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.1.y"
>
>  require linux-raspberrypi.inc

Hi Raj,

Merged to master. Thank you.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH v2 3/7] linux-raspberrypi: Update 4.1 recipe to 4.1.15

2016-02-29 Thread Andrei Gherzan 
On Sun, Feb 28, 2016 at 02:44:36PM +0100, Petter Mabäcker wrote:
>2016-02-28 12:02 skrev Andrei Gherzan:
>
> On Sun, Feb 28, 2016 at 11:51:58AM +0100, Andrei Gherzan wrote:
>
>  On Sun, Feb 28, 2016 at 08:56:33AM +0100, Petter Mab�cker wrote:
>
>  2016-01-14 17:40 skrev Petter Mab?cker: [Support #69] Signed-off-by:
>  Petter Mab?cker <[1][1]pet...@technux.se> ---
>  recipes-kernel/linux/linux-raspberrypi_4.1.bb | 4 ++-- 1 file
>  changed, 2 insertions(+), 2 deletions(-) diff --git
>  a/recipes-kernel/linux/linux-raspberrypi_4.1.bb
>  b/recipes-kernel/linu x/linux-raspberrypi_4.1.bb index
>  3a3cf40..cae459a 100644 ---
>  a/recipes-kernel/linux/linux-raspberrypi_4.1.bb +++
>  b/recipes-kernel/linux/linux-raspberrypi_4.1.bb @@ -1,6 +1,6 @@
>  -LINUX_VERSION ?= "4.1.10" +LINUX_VERSION ?= "4.1.15" -SRCREV =
>  "b74df9228c27f55361c065bc5dbfba88861cc771" +SRCREV =
>  "02a8ee530e32b08e5df44f10e24d5fd82bb960e3" SRC_URI =
>  "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.1.
>  y " require linux-raspberrypi.inc Hi Andrei, This commit can be
>  skipped, since Khem have done an even newer update of the 4.1 kernel
>  (4.1.10 --> 4.1.17) in the large series of commits from yesterday
>  ([2]https://lists.yoctoproject.org/pipermail/yocto/2016-February/028
>  754.ht ml). Do you want me to send an updated version of this series
>  of commit without it or not? BR Petter References 1.
>  mailto:[3]pet...@technux.se
>
>  Thanks Peter. No need to bother. I'll keep in mind not to pull this
>  patch.
>
> Petter,
>
> Actually I do have a request. Could you please send the v2 again (or a v3)
> cause even if they are on the ml archive I don't have it in my mailbox (this
> kinda worries me). Sorry for this and thank you in advance.
>
> --
> Andrei Gherzan
>
>I will send up a v3 with the kernel bump commit removed (and also a fix
>for a minor typo in the README..).
>
>BR Petter

Thank you Peter. This is the next one in line for testing and merging.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH v4 1/2] linux-raspberry.inc: add initramfs support

2016-02-29 Thread Andrei Gherzan 
On Sun, Feb 28, 2016 at 12:48:35PM +0100, Andrei Gherzan wrote:
> From: Stéphane Cerveau 
>
> append initramfs creation to install RPi bootloader trailer
>
> Signed-off-by: Stéphane Cerveau 
> Signed-off-by: Andrei Gherzan 
> ---
>  recipes-kernel/linux/linux-raspberrypi.inc | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index 8c7c46c..1befee4 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -64,4 +64,14 @@ do_rpiboot_mkimage() {
>  fi
>  fi
>  }
> +
> +do_bundle_initramfs_append() {
> +if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
> +if test -n "${KERNEL_DEVICETREE}"; then
> +# Add RPi bootloader trailer to kernel image to enable 
> DeviceTree support
> +${STAGING_LIBEXECDIR_NATIVE}/mkknlimg --dtok 
> ${KERNEL_OUTPUT}.initramfs ${KERNEL_OUTPUT}.initramfs
> +fi
> +fi
> +}
> +
>  addtask rpiboot_mkimage before do_install after do_compile
> --
> 2.7.0
>

Merged both patches to master.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Standalone image writer

2016-02-29 Thread Philip Balister 
On 02/29/2016 02:52 PM, Paul Eggleton wrote:
> On Mon, 29 Feb 2016 11:27:15 Barros Pena, Belen wrote:
>> On 29/02/2016 08:12, "yocto-boun...@yoctoproject.org on behalf of Paul
>> Eggleton" > paul.eggle...@linux.intel.com> wrote:
>>> There isn't a frontend UI for wic that I am aware of though - as I
>>> mentioned earlier image-writer has no support for it, it's just doing a
>>> straight dd to the device.
>>
>> We would really like to add support for wic at some point.
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769
> 
> True, but that's a slightly different usage of wic - i.e. preparing the 
> formatted image, which we should support. However, writing a formatted image 
> to an SD card / USB stick isn't something you could practically do from a web-
> based application I don't think - not without help from a local application 
> at 
> any rate.

For writing the output of wic to an mmc card, I use wic. I believe it is
available as an Ubuntu package and works well on Fedora.

https://source.tizen.org/documentation/reference/bmaptool/bmap-tools-project

Philip

> 
> Cheers,
> Paul
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Standalone image writer

2016-02-29 Thread Paul Eggleton 
On Mon, 29 Feb 2016 11:27:15 Barros Pena, Belen wrote:
> On 29/02/2016 08:12, "yocto-boun...@yoctoproject.org on behalf of Paul
> Eggleton"  paul.eggle...@linux.intel.com> wrote:
> >There isn't a frontend UI for wic that I am aware of though - as I
> >mentioned earlier image-writer has no support for it, it's just doing a
> >straight dd to the device.
> 
> We would really like to add support for wic at some point.
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769

True, but that's a slightly different usage of wic - i.e. preparing the 
formatted image, which we should support. However, writing a formatted image 
to an SD card / USB stick isn't something you could practically do from a web-
based application I don't think - not without help from a local application at 
any rate.

Cheers,
Paul

-- 

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

Re: [yocto] hello world fails in eclipse

2016-02-29 Thread Mark Hatle 
On 2/29/16 8:35 AM, Markus Haege wrote:
> Hello there,
> 
> I searched the web for a while, figured out that I'm not the first person with
> this problem
> but I don't find the solution.
> 
> I use Debian 8 with Eclipse luna Release 2.
> I installed the yocto plugins in eclipse as described in the manual.
> 
> Now I want to compile a hello world for the meta-raspberrypi but it fails:
> 
> The C compiler
>  
> "/home/markus/poky/meta-raspberrypi/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc"
>   is not able to compile a simple test program.
> 
> /home/markus/poky/meta-raspberrypi/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
>   error: cmTryCompileExec1319352149 uses VFP register arguments,
>   CMakeFiles/cmTryCompileExec1319352149.dir/testCCompiler.c.o does not

I'm not sure about the eclipse aspect of this, but the failure is indicating
that one item is trying to use one ABI, and other items are using a different
ABI.  Resulting in incompatibilities.  (This for ARM is EABI and HF EABI --
error says "cmTryCompileExec1319352149" is the HF EABI.)

About the best I can suggest it to check that eclipse imported not only the name
of the compile, but also the required compiler (and linker) arguments from the
environment file.

Also verify that any produced make (cmake) files are not overriding the compile
and link cflags with something else.

> I sourced the environment setup so eclipse finds under
> properties/C++Build/Environment the settings. That's all I achieved.
> I read about flags to set but don't know where. Something about floating 
> point.
> What I read was very old.

The flags in question that are incompatible are:

-mfloat-abi=hard
-mfloat-abi=softfp

--Mark

> Thanks to any help
> 
> Markus
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Hanging during kernel boot

2016-02-29 Thread Clark, Mark A 
I am running into the same problem and have tried tweaking parts of the kernel 
config to get past this.  I can build the same target for qemu and it boots 
fine.  I run it on a Beckhoff SBC and it hangs at the Switching to clock source 
tsc".



Any ideas?  It's using the 3.14 kernel for RT.



"I've been redoing an old Danny project with Fido, running on an Atom mobo.

I created a fresh BSP with yocto-bsp, using a RT kernel, and haven't begun

to fiddle with the kernel configuration yet. It gets part way through the

boot process and hangs at "Switching to clocksource tsc". I've googled

this error, which lots of people have had on lots of systems (Ubuntu,

etc.), and have solved in lots of different ways, none of which seem to

relate to my system. I don't believe it has anything to do with the tsc.



The system doesn't crash. I can bang on the keyboard, and the keys are

echoed. After seven or so presses, I get a "random: nonblocking pool is

initialized" message (something to do with entropy collection, I guess).

So the kernel is running, but it's like systemd (which I've substituted

for sysvinit) has just hung.



Since I haven't gotten to a prompt, I can't do anything. Does anyone have

any ideas how I might diagnose this? Are there any kernel parameters I

might fiddle with on the flash memory? And where does one do such

fiddling, with a syslinux-based live image? Or should I be selectively

removing things from my BSP that were put there by yocto-bsp?



--



Ciao,   Paul D. DeRocco

Paulmailto:pderocco at 
ix.netcom.com


"

Mark Clark
Embedded Software Engineer
Embedded Software, Cedar Park, TX
[Description: Description: Description: Description: National Oilwell Varco 
Logo Color CMYK.jpg]
 Wellbore Technologies - Dynamic Drilling Solutions
Global Software Engineering
Office: (512) 340-5435
Mobile: (512) 736-9396
"One Team - Infinite Solutions"

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] hello world fails in eclipse

2016-02-29 Thread Markus Haege 
Hello there,

I searched the web for a while, figured out that I'm not the first person
with this problem
but I don't find the solution.

I use Debian 8 with Eclipse luna Release 2.
I installed the yocto plugins in eclipse as described in the manual.

Now I want to compile a hello world for the meta-raspberrypi but it fails:

The C compiler

"/home/markus/poky/meta-raspberrypi/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc"
  is not able to compile a simple test program.

/home/markus/poky/meta-raspberrypi/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
  error: cmTryCompileExec1319352149 uses VFP register arguments,
  CMakeFiles/cmTryCompileExec1319352149.dir/testCCompiler.c.o does not

I sourced the environment setup so eclipse finds under
properties/C++Build/Environment the settings. That's all I achieved.
I read about flags to set but don't know where. Something about floating
point. What I read was very old.

Thanks to any help

Markus
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Fix booting from eMMC on BeagleBone Black

2016-02-29 Thread Jussi Laako 

Hello,

By default, on BeagleBone, u-boot only looks for rootfs UUID from first 
mmc device and thus only from microSD. Thus booting from eMMC fails in 
kernel panic because command line has empty root partition UUID 
"root=PARTUUID=".


This patch makes it first look in the same place as before and if the 
lookup fails (no microSD inserted) it next looks up for the rootfs UUID 
on the second mmc device which is the on-board eMMC. I placed the 
bbappend and patch on meta-yocto-bsp layer because the BeagleBone 
support in general is located there.



Best regards,

- Jussi Laako

>From f54171b120b1fa47a592bdb8f3fbac2350e1757e Mon Sep 17 00:00:00 2001
From: Jussi Laako 
Date: Mon, 29 Feb 2016 16:12:11 +0200
Subject: [PATCH] Search for rootfs partitions on both SD and eMMC

On BeagleBone Black, first attempt to find rootfs from microSD
and then from eMMC if not available.

Fixes: #9176

Signed-off-by: Jussi Laako 
---
 ...r-bootable-partitions-on-both-SD-and-eMMC.patch | 38 ++
 .../recipes-bsp/u-boot/u-boot_2016.01.bbappend |  3 ++
 2 files changed, 41 insertions(+)
 create mode 100644 meta-yocto-bsp/recipes-bsp/u-boot/u-boot/0001-Search-for-bootable-partitions-on-both-SD-and-eMMC.patch
 create mode 100644 meta-yocto-bsp/recipes-bsp/u-boot/u-boot_2016.01.bbappend

diff --git a/meta-yocto-bsp/recipes-bsp/u-boot/u-boot/0001-Search-for-bootable-partitions-on-both-SD-and-eMMC.patch b/meta-yocto-bsp/recipes-bsp/u-boot/u-boot/0001-Search-for-bootable-partitions-on-both-SD-and-eMMC.patch
new file mode 100644
index 000..729dddf
--- /dev/null
+++ b/meta-yocto-bsp/recipes-bsp/u-boot/u-boot/0001-Search-for-bootable-partitions-on-both-SD-and-eMMC.patch
@@ -0,0 +1,38 @@
+From 86cc560ff9a6578326532e277d987e24661e5f04 Mon Sep 17 00:00:00 2001
+From: Jussi Laako 
+Date: Fri, 26 Feb 2016 14:58:32 +0200
+Subject: [PATCH] Search for bootable partitions on both SD and eMMC
+
+On BeagleBone Black, first attempt to boot from microSD and then from
+eMMC if not available.
+
+Signed-off-by: Jussi Laako 
+---
+ include/configs/ti_armv7_common.h | 11 ++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
+index 199612b..ece87ab 100644
+--- a/include/configs/ti_armv7_common.h
 b/include/configs/ti_armv7_common.h
+@@ -60,7 +60,16 @@
+ #define DEFAULT_MMC_TI_ARGS \
+ 	"mmcdev=0\0" \
+ 	"mmcrootfstype=ext4 rootwait\0" \
+-	"finduuid=part uuid mmc 0:2 uuid\0" \
++	"findsduuid=part uuid mmc 0:2 sduuid\0" \
++	"findemmcuuid=part uuid mmc 1:2 emmcuuid\0" \
++	"finduuid=if run findsduuid; then "\
++		"echo \"Boot from microSD\"; "\
++		"setenv uuid ${sduuid}; " \
++	"else " \
++		"run findemmcuuid; " \
++		"echo \"Boot from eMMC\"; " \
++		"setenv uuid ${emmcuuid}; " \
++	"fi;\0" \
+ 	"args_mmc=run finduuid;setenv bootargs console=${console} " \
+ 		"${optargs} " \
+ 		"root=PARTUUID=${uuid} rw " \
+-- 
+2.7.0
+
diff --git a/meta-yocto-bsp/recipes-bsp/u-boot/u-boot_2016.01.bbappend b/meta-yocto-bsp/recipes-bsp/u-boot/u-boot_2016.01.bbappend
new file mode 100644
index 000..01c8e68
--- /dev/null
+++ b/meta-yocto-bsp/recipes-bsp/u-boot/u-boot_2016.01.bbappend
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append = " file://0001-Search-for-bootable-partitions-on-both-SD-and-eMMC.patch"
-- 
2.7.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] git recipes

2016-02-29 Thread Mark Hatle 
On 2/27/16 10:23 PM, Philip Tricca wrote:
> Adding a sensible subject.

Sorry couldn't reply when I saw this when you first sent it.  Corporate email
server went down for those of us who DON'T use outlook.. argh..

Anyway..

What I'm generally used to in the Yocto Project work is that the 'git' version
picks a specific git snapshot and makes it a quick operation for someone to
arbitrarily change that snapshot by adjusting the SRCREV.

We don't use the AUTOREV parameter, because that causes the system to have to do
a git pull in order to evaluate the available versions and determine the SRCREV
to use.  So it's all down to a parsing and performance issue.

What I've done on some of my own projects is have an AUTOREV version (locally),
then when it triggers a recipe breakage, I think update the SRCREV and fix it in
the remote tree..  so I get the autorev, the world gets a version of the package
that keeps working.  (I also update the SRCREV other times as well.. but the
autorev breakage is one of the key triggers.)

Joe might have some suggestions as well, I'm not against AUTOREV per say, but I
am worried about any performance issues during the parse.

--Mark

> On 02/27/2016 08:17 PM, Philip Tricca wrote:
>> While going through the backlog I ran across the 'git' versions of the
>> user space. I noticed that a recent contribution was adding a patch to
>> the git recipe and I figured that this patch would already be upstream
>> and so wouldn't be necessary. Not so. The 'git' versions have SRCREV
>> hard wired (SRCREV) to a commit id but it's way back from the end of
>> 2013. They're also disabled via DEFAULT_PREFERENCE = "-1"
>>
>> These 'git' versions seem super useful for testing bleeding edge stuff
>> so IMHO keeping them around would be the right thing to do. Not sure how
>> I feel about them tracking an ancient commit though. Since they're never
>> built by default it seems reasonable to track the master branch.
>>
>> What's our philosophy w/r to recipes that pull from git? Is there some
>> history behind this SRCREV?
>>
>> Thanks,
>> Philip
>>
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Removing Hob for 2.1

2016-02-29 Thread Barros Pena, Belen 


On 26/02/2016 15:29,
"openembedded-architecture-boun...@lists.openembedded.org on behalf of
nick"  wrote:

>I was wondering for people somewhat used to using HOB for easier
>distribution build tuning how big is the learning curve

Well, this is a question only those people can answer :) and I would be
very interested in hearing what they have to say.

So, if you consider yourself one those people "somewhat used to using
HOB", and would like to try Toaster and give us some feedback, please
contact me off list.

Cheers,

Belén

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Standalone image writer

2016-02-29 Thread Barros Pena, Belen 


On 29/02/2016 08:12, "yocto-boun...@yoctoproject.org on behalf of Paul
Eggleton"  wrote:

>There isn't a frontend UI for wic that I am aware of though - as I
>mentioned 
>earlier image-writer has no support for it, it's just doing a straight dd
>to 
>the device.

We would really like to add support for wic at some point.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769

Maybe 2.1?

Cheers

Belén

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto