Re: [yocto] Morty 2.2.1 build failure

2017-03-24 Thread Jussi Kukkonen 
On 23 March 2017 at 22:11, Greg Wilson-Lindberg 
wrote:

> Hi Armin & Paul,
>
> First there is nothing in the X log files.
> I'm building on a desktop machine with 12GB of memory and an 8 core
> processor running Kubuntu 14.04.
> I added the PARALLEL_MAKE parameter set to 4, no effect, still built with
> 8 threads, crashed.
> Set BB_NUMBER_THREADS to 4, built with 4 threads, still crashed.
>

Getting thrown out of your desktop environment probably indicates the core
problem is outside of Yocto -- this is still a fine place to discuss the
issue, just pointing it out. You could keep an eye on 'top' sorted by %MEM
while doing a build: my theory here is that something (like the monstrous
amount of IO) that the build does could trigger a desktop component to do
something stupid that cascades into your desktop shell exiting/crashing.
This could show up as something using more and more memory at some point
during the build.

Hope this helps, sorry for lack of definitive answers,
  Jussi



>
> Regards,
> Greg
>
> > -Original Message-
> > From: akuster [mailto:akus...@mvista.com]
> > Sent: Thursday, March 23, 2017 12:33 PM
> > To: Greg Wilson-Lindberg 
> > Cc: Paul Eggleton ;
> yocto@yoctoproject.org
> > Subject: Re: [yocto] Morty 2.2.1 build failure
> >
> >
> >
> > On 03/23/2017 12:25 PM, Paul Eggleton wrote:
> > > That's really bizarre. There shouldn't be anything in a bitbake build
> > > that could cause anything like this (other than possibly how intensive
> > > it is, which might trigger out-of-memory or an underlying
> > hardware/software failure).
> >
> > I usually get my builds to reboot my system when I build on a loptop. I
> have
> > not seen this on a tower style work station. You may want to play with
> the
> > BB_NUMBER_THREADS=# and PARALLEL_MAKE = "-j #" settings in your
> > local.conf.
> >
> > - armin
> > >
> > > Assuming the X session is ending is there anything in your
> > > ~/.xsession-errors or /var/log/Xorg.*.log?
> > >
> > > Cheers,
> > > Paul
> > >
> > > On Friday, 24 March 2017 5:58:24 AM NZDT Greg Wilson-Lindberg wrote:
> > >> Hi Paul,
> > >>
> > >> I looked in the logs from the failure yesterday and couldn't find
> > >> anything, so I restarted the build and it ran for about another 1000
> > >> steps before crashing again. I still can't find anything in any of
> > >> the logs, syslog, kern.log, auth.log, etc.
> > >>
> > >> Cheers,
> > >> Greg
> > >>
> > >>> -Original Message-
> > >>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> > >>> Sent: Thursday, March 23, 2017 2:49 AM
> > >>> To: Greg Wilson-Lindberg 
> > >>> Cc: yocto@yoctoproject.org; akuster808 
> > >>> Subject: Re: [yocto] Morty 2.2.1 build failure
> > >>>
> > >>> On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg
> > wrote:
> >  I tried it again this morning and it did get past the file not
> >  found error.
> >  But when it gets above step 4000 somewhere it gets an error that
> >  kills not just the yocto build but the full login session. I'm left
> >  staring at the Linux Login screen.
> > >>> Your machine isn't running out of RAM by any chance, triggering the
> > >>> OOM killer? Anything indicative in your system logs?
> > >>>
> > >>> Cheers,
> > >>> Paul
> > >>>
> > >>> --
> > >>>
> > >>> Paul Eggleton
> > >>> Intel Open Source Technology Centre
> > >
>
> --
> ___
> 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] [meta-security] master-next rebased?

2017-03-24 Thread Patrick Ohly 
Hello Armin!

Did you accidentally rebase all of master-next?

The current master-next tip (3b9dd3688b6c725aa0146c91ee1a58c26095e48d)
isn't rooted in the current master
(8b38c93f2387793fb03d082e47723002cf667ae9) anymore:

$ git branch -r --contains origin/master-next 
  origin/master-next
$ git log --oneline origin/master..origin/master-next  | wc -l
179
$ git log --oneline origin/master  | wc -l
211

Looking at the content, it seems that only the last two commits in
master-next are actually new ;-}

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[yocto] [PATCH v2] logrotate: Add systemd support

2017-03-24 Thread Romain Perier 
Currently, this recipe only supports daily scheduling via a cron job.
This commit adds support for systemd, including systemd service and
systemd timer. When the corresponding distro feature is enabled the
systemd variant will be used. The timer granularity and its accuracy
are also configurable.

Signed-off-by: Romain Perier 
---

Changes in v2:
- Make the systemd timer configurable (as this is distribution or target 
specific)

 .../logrotate/logrotate/logrotate.service  |  9 
 .../logrotate/logrotate/logrotate.timer|  7 ++
 meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 27 --
 3 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.service
 create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.timer

diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.service 
b/meta/recipes-extended/logrotate/logrotate/logrotate.service
new file mode 100644
index 000..3edb8ef
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.service
@@ -0,0 +1,9 @@
+[Unit]
+Description=Rotate log files
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
+Nice=19
+IOSchedulingClass=best-effort
+IOSchedulingPriority=7
diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.timer 
b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
new file mode 100644
index 000..c616b43
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
@@ -0,0 +1,7 @@
+[Unit]
+Description=Daily rotation of log files
+
+[Timer]
+OnCalendar=@TIMER_BASIS@
+AccuracySec=@TIMER_ACCURACY@
+Persistent=true
diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb 
b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
index 5f1a601..6953996 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
@@ -14,6 +14,8 @@ SRC_URI = 
"https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.g
file://act-as-mv-when-rotate.patch \
file://update-the-manual.patch \
file://disable-check-different-filesystems.patch \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'file://logrotate.service', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'file://logrotate.timer', '', d)} \
 "
 
 SRC_URI[md5sum] = "4492b145b6d542e4a2f41e77fa199ab0"
@@ -47,6 +49,17 @@ EXTRA_OEMAKE = "\
 # INSTALL=install and BASEDIR=/usr.
 OS_NAME = "Linux"
 
+inherit systemd
+
+SYSTEMD_AUTO_ENABLE = "disable"
+SYSTEMD_SERVICE_${PN} = "\
+${PN}.service \
+${PN}.timer \
+"
+
+LOGROTATE_SYSTEMD_TIMER_BASIS ?= "daily"
+LOGROTATE_SYSTEMD_TIMER_ACCURACY ?= "12h"
+
 do_compile_prepend() {
 # Make sure the recompile is OK
 rm -f ${B}/.depend
@@ -55,9 +68,19 @@ do_compile_prepend() {
 do_install(){
 oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
 mkdir -p ${D}${sysconfdir}/logrotate.d
-mkdir -p ${D}${sysconfdir}/cron.daily
 mkdir -p ${D}${localstatedir}/lib
 install -p -m 644 examples/logrotate-default 
${D}${sysconfdir}/logrotate.conf
-install -p -m 755 examples/logrotate.cron 
${D}${sysconfdir}/cron.daily/logrotate
 touch ${D}${localstatedir}/lib/logrotate.status
+
+# Install systemd unit files
+if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', 
d)}" = "systemd" ]; then
+install -d ${D}/${systemd_system_unitdir}
+install -m 0644 ${WORKDIR}/logrotate.service 
${D}/${systemd_system_unitdir}/logrotate.service
+install -m 0644 ${WORKDIR}/logrotate.timer 
${D}/${systemd_system_unitdir}/logrotate.timer
+sed -i -e 's,@TIMER_BASIS@,${LOGROTATE_SYSTEMD_TIMER_BASIS},g' 
${D}${systemd_system_unitdir}/logrotate.timer
+sed -i -e 's,@TIMER_ACCURACY@,${LOGROTATE_SYSTEMD_TIMER_ACCURACY},g' 
${D}${systemd_system_unitdir}/logrotate.timer
+else
+mkdir -p ${D}${sysconfdir}/cron.daily
+install -p -m 0755 examples/logrotate.cron 
${D}${sysconfdir}/cron.daily/logrotate
+fi
 }
-- 
1.8.3.1

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

Re: [yocto] [meta-swupd] allow username/password encoded in SWUPD_VERSION_URL and SWUPD_CONTENT_URL

2017-03-24 Thread Patrick Ohly 
On Thu, 2017-03-23 at 16:04 +0100, Ingo Flaschberger wrote:
> This patch allows basic authentication of swupd SWUPD_VERSION_URL and 
> SWUPD_CONTENT_URL.
> swupd-client already support urlencoded username/password, but 
> buildlayer does not.

Can you resend in "git format-patch" format? Don't forget the
signed-off-by and add short prefix to the summary line, perhaps like
this:
bundles.py: allow username/password encoded into HTTP server URLs

An example how username/password need to be encoded in the URL would
also be useful.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[yocto] [meta-security][PATCH] swtpm-wrappers: wrap more commands

2017-03-24 Thread Patrick Ohly 
Soon it might be possible to let qemu start swtpm directly, without
requiring root privileges as for swtpm_cuse. For that to work
we also need to wrap the swtpm binary. Just in case we now also
do it for everything.

Signed-off-by: Patrick Ohly 
---
 recipes-tpm/swtpm/swtpm-wrappers.bb | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/recipes-tpm/swtpm/swtpm-wrappers.bb 
b/recipes-tpm/swtpm/swtpm-wrappers.bb
index 676c35e..0af1db6 100644
--- a/recipes-tpm/swtpm/swtpm-wrappers.bb
+++ b/recipes-tpm/swtpm/swtpm-wrappers.bb
@@ -9,7 +9,13 @@ inherit native
 RM_WORK_EXCLUDE += "${PN}"
 
 do_create_wrapper () {
-cat >${WORKDIR}/swtpm_setup_oe.sh <${WORKDIR}/swtpm_setup_oe.sh <${WORKDIR}/swtpm_cuse_oe.sh <${WORKDIR}/${exe}_oe.sh

Re: [yocto] [meta-security][PATCH] tpm2.0-tss: install resourcemgr service

2017-03-24 Thread Patrick Ohly 
On Thu, 2017-03-23 at 15:26 +0100, Benjamin Gaignard wrote:
> +diff --git a/contrib/resourcemgr.service b/contrib/resourcemgr.service
> +index 7f23739..e5b0900 100644
> +--- a/contrib/resourcemgr.service
>  b/contrib/resourcemgr.service
> +@@ -3,7 +3,7 @@ Description=TPM2 resource manager & access broker
> + Documentation=http://www.github.com/01org/TPM2.0-TSS
> + 
> + [Service]
> +-ExecStart=/usr/local/sbin/resourcemgr
> ++ExecStart=/usr/sbin/resourcemgr
> + StandardOutput=null
> + User=tss
> + Group=tss
> +-- 
> +1.9.1

I think it would be better to patch the actual ${sbindir} into the
resourcemgr.service file, instead of assuming that ${sbindir}
= /usr/sbin and using a static patch.

Something like this:

do_patch[postfuncs] += "fix_systemd_unit"
fix_systemd_unit () {
sed -i -e 's;^ExecStart=.*/resourcemgr;ExecStart=${sbindir}/resourcemgr;' 
${S}/contrib/resourcemgr.service
}

Just my 2 cents.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [yocto] Buildbot / Autobuilder / custom?

2017-03-24 Thread Joshua Lock 
Hi Alain,
On Thu, 2017-03-23 at 17:40 -0400, Alain Achkar wrote:
> I followed http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder/tre
> e/README-QUICKSTARTand got:


> checking controller.cfg
> LOADING CONFIG FILE
> error while parsing config file:
> Traceback (most recent call last):
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/Twisted-12.2.0-py2.7-linux-
> x86_64.egg/twisted/internet/defer.py", line 1187, in unwindGenerator
>     return _inlineCallbacks(None, gen, Deferred())
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/Twisted-12.2.0-py2.7-linux-
> x86_64.egg/twisted/internet/defer.py", line 1045, in _inlineCallbacks
>     result = g.send(result)
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/buildbot-0.8.8-
> py2.7.egg/buildbot/scripts/upgrade_master.py", line 169, in
> upgradeMaster
>     master_cfg = loadConfig(config, configFile)
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/buildbot-0.8.8-
> py2.7.egg/buildbot/scripts/upgrade_master.py", line 53, in loadConfig
>     config['basedir'], configFileName)
> ---  ---
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/buildbot-0.8.8-py2.7.egg/buildbot/config.py", line 149, in
> loadConfig
>     exec f in localDict
>   File "/media/data/yocto-autobuilder/yocto-
> controller/controller.cfg", line 94, in 
>     yocto_buildsets.createBuildsets()
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/autobuilder/Autobuilder.py", line 65, in createBuildsets
>     self.parseBuildSet(buildset)
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/autobuilder/Autobuilder.py", line 102, in parseBuildSet
>     self.parseRepos(buildset)
>   File "/media/data/yocto-autobuilder/lib/python2.7/site-
> packages/autobuilder/Autobuilder.py", line 127, in parseRepos
>     if layer.iterkeys().next() not in self.repos:
> exceptions.AttributeError: 'list' object has no attribute 'iterkeys'

I appear to have left a stray comma in buildset-
config.controller/nightly.conf which causes the parser to choke. I've
fixed this in the master branch of yocto-autobuilder: http://git.yoctop
roject.org/clean/cgit.cgi/yocto-
autobuilder/commit/?id=239eeaa1e2cf3a985e75f8b75dedfe704a7d6991

You'll need to edit buildset-config/nightly.conf on your local instance
similarly to remove the comma at the end of the repos list, around line
38.
Thanks for reporting this error!
Joshua
> Errors loading configuration:
>   error while parsing config file: 'list' object has no attribute
> 'iterkeys' (traceback in logfile)
>  To start the autobuilder:
>  ./yocto-start-autobuilder 
> 
> 
>  To stop the autobuilder:
>  ./yocto-stop-autobuilder 
> 
> 
> >0< alain@esxi-ub1 Thu Mar 23 05:34 PM [master !?] /media/data/yocto-
> autobuilder >
> 
> 
> Any ideas on how to fix this?
> On Mon, Nov 14, 2016 at 1:40 PM, Bill Randle 
> wrote:
> > Yes, the 2 TB is for everything you might do with an AutoBuilder.
> > The
> > 
> > actual space used will be closer to your 35 GB, since you're
> > building
> > 
> > only a single image / work product. People have used BuilBot
> > directly
> > 
> > for automated builds, but using the AutoBuilder code (which runs
> > 
> > BuildBot underneath) gives you added flexibility and capability
> > 
> > without much additional overhead.
> > 
> > 
> > 
> >     -Bill
> > 
> > 
> > 
> > On Mon, Nov 14, 2016 at 8:13 AM, Alain Achkar  > .com> wrote:
> > 
> > > Thanks for your answers! From reading these links, it is still
> > not clear to
> > 
> > > me if this might be overkill for my requirements. AB Cluster
> > Setup talks
> > 
> > > about "the worker requires 2+ TB to hold all the build temp files
> > and git
> > 
> > > repos. If build artifacts and a local sstate mirror are included,
> > additional
> > 
> > > worker space is required."
> > 
> > >
> > 
> > > Currently, my build only takes 35GB, so I think what these links
> > are talking
> > 
> > > about is how to replicate what the Autobuilder project
> > 
> > > https://autobuilder.yoctoproject.org/ already does.
> > 
> > >
> > 
> > > To clarify, I am not interested in running builds and tests for
> > everything
> > 
> > > that Yocto already builds and tests (i.e. all the processor
> > architectures,
> > 
> > > all the machine types, etc.).  I am interested in running one
> > build for one
> > 
> > > machine type (the Variscite DART-6UL i.MX6UL arm-based processor,
> > for which
> > 
> > > NXP/Freescale and Variscite have provided recipes and layers
> > for).
> > 
> > >
> > 
> > > I know that autobuilder includes BuildBot (this is why I
> > specified it in
> > 
> > > parentheses) but my question remains: do I only install BuildBot
> > and try to
> > 
> > > build my machine type with it, or do I install Autobuilder?
> > 
> > >
> > 
> > > On Mon, Nov 14, 2016 at 10:10 AM, Bill Randle  > com> wrote:
> > 
> > >>
> > 
> > >> Also, be sure to check the Yocto Project wiki pages:
> > 
> > >>     h

[yocto] [meta-security][PATCH v2] tpm2.0-tss: install resourcemgr service

2017-03-24 Thread Benjamin Gaignard 
Install systemd resource.mgr service and it needed user/group.

version 2:
- do not hardcode sbin directory in a patch but use ${sbindir} instead

Signed-off-by: Benjamin Gaignard 
---
 recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb 
b/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
index a03559c..ca82562 100644
--- a/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
+++ b/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
@@ -10,7 +10,7 @@ SRC_URI = " \
 file://ax_pthread.m4 \
 file://fix_musl_select_include.patch "
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig systemd
 
 S = "${WORKDIR}/${@d.getVar('BPN',d).upper()}"
 
@@ -24,6 +24,26 @@ do_configure_prepend () {
cd $currentdir
 }
 
+INHERIT += "extrausers"
+EXTRA_USERS_PARAMS = "\
+   useradd -p '' tss; \
+   groupadd tss; \
+   "
+
+SYSTEMD_PACKAGES += "resourcemgr"
+SYSTEMD_SERVICE_resourcemgr = "resourcemgr.service"
+SYSTEMD_AUTO_ENABLE_resourcemgr = "enable"
+
+do_patch[postfuncs] += "fix_systemd_unit"
+fix_systemd_unit () {
+sed -i -e 's;^ExecStart=.*/resourcemgr;ExecStart=${sbindir}/resourcemgr;' 
${S}/contrib/resourcemgr.service
+}
+
+do_install_append() {
+install -d ${D}${systemd_system_unitdir}
+install -m0644 ${S}/contrib/resourcemgr.service 
${D}${systemd_system_unitdir}/resourcemgr.service
+}
+
 PROVIDES = "${PACKAGES}"
 PACKAGES = " \
 ${PN}-dbg \
@@ -64,4 +84,4 @@ FILES_libtctisocket-dev = " \
 ${libdir}/pkgconfig/tcti-socket.pc \
 "
 FILES_libtctisocket-staticdev = "${libdir}/libtcti-socket.*a"
-FILES_resourcemgr = "${sbindir}/resourcemgr"
+FILES_resourcemgr = "${sbindir}/resourcemgr 
${systemd_system_unitdir}/resourcemgr.service"
-- 
1.9.1

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

[yocto] PHP5 Recipe

2017-03-24 Thread Stefano Zuín 

Good Morning,

I am trying to use php in a simple poky kernel in a core-image-minimal 
image. But I have some problems to get it working. I have also tried 
using core-image-full-cmdline image having the same result explained 
after this.


When I cook the recipe everything is OK. I can find inside the 
/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.23-r0/image/ directory 
all the necessary files to have php running. but unfortunately, when I 
run the emulator with my image I can't find all these files. Just in 
/usr/lib/php5/php/ are Structures and XML directories. I have also added 
in my conf/local.conf file IMAGE_INSTALL_append=" php".


It is necessary to add another recipe in order to use php?? Is there 
something that Im missing?

--


*Stefano Zuin Castillo*
Ingeniero de Software
email: sz...@kiversal.com 
Tel: +34 93 551 14 94





*DEVIMETRIX, S.L.*
C/ Llacuna 162, módulo 118
08018 Barcelona (SPAIN)
www.kiversal.com 



Este correo electrónico y sus documentos adjuntos contienen información 
privilegiada, personal y estrictamente confidencial, y está prohibida la copia, 
reenvío o utilización de la información.
Si usted no es la persona destinataria del presente mensaje, no está autorizada 
a leerlo, retenerlo o difundirlo.

This e-mail and its attachments are privileged, confidential and contain 
private information, and any sending, using or copy of its information is 
prohibited.
Any person other than its intended recipient is not authorised to read, retain 
or distribute this information.

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

[yocto] quoted string in a recipe variable?

2017-03-24 Thread Takashi Matsuzawa 
Hello, Yocto.
I am a bit confused with recipe syntax for variable assignment.

I wanto embed double-quoted string within a variable.
And I tried below and looks like the whole part of the string (A to B) is 
successfully assigned to EXTRA_OECMAKE variable.

EXTRA_OECMAKE = " \ <-- A
  "-D CMAKE_= \
  ...
  ...
  -D CMAKE_=" \
" <-- B

My question is, if this is a valid way of doing it?
Why bitbake parser is not confused?


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

Re: [yocto] Morty 2.2.1 build failure

2017-03-24 Thread Dan Riegsecker 
For whatever it is worth, I am experiencing the same issue. I’m running a 
Lenovo ThinkStation P910 with two Intel Xeon E5-2630 v4 CPUs and 64 GB of RAM. 
I’m running Ubuntu 16.04. I also have been unable to find much useful 
information in the logs, but when running bitbake, lightdm just restarts and I 
end up at a log in screen with all running programs halted.

Thanks,
Dan
> On Mar 24, 2017, at 4:17 AM, Jussi Kukkonen  wrote:
> 
> On 23 March 2017 at 22:11, Greg Wilson-Lindberg  > wrote:
> Hi Armin & Paul,
> 
> First there is nothing in the X log files.
> I'm building on a desktop machine with 12GB of memory and an 8 core processor 
> running Kubuntu 14.04.
> I added the PARALLEL_MAKE parameter set to 4, no effect, still built with 8 
> threads, crashed.
> Set BB_NUMBER_THREADS to 4, built with 4 threads, still crashed.
> 
> Getting thrown out of your desktop environment probably indicates the core 
> problem is outside of Yocto -- this is still a fine place to discuss the 
> issue, just pointing it out. You could keep an eye on 'top' sorted by %MEM 
> while doing a build: my theory here is that something (like the monstrous 
> amount of IO) that the build does could trigger a desktop component to do 
> something stupid that cascades into your desktop shell exiting/crashing. This 
> could show up as something using more and more memory at some point during 
> the build.
> 
> Hope this helps, sorry for lack of definitive answers,
>   Jussi
> 
>  
> 
> Regards,
> Greg
> 
> > -Original Message-
> > From: akuster [mailto:akus...@mvista.com ]
> > Sent: Thursday, March 23, 2017 12:33 PM
> > To: Greg Wilson-Lindberg  > >
> > Cc: Paul Eggleton  > >; yocto@yoctoproject.org 
> > 
> > Subject: Re: [yocto] Morty 2.2.1 build failure
> >
> >
> >
> > On 03/23/2017 12:25 PM, Paul Eggleton wrote:
> > > That's really bizarre. There shouldn't be anything in a bitbake build
> > > that could cause anything like this (other than possibly how intensive
> > > it is, which might trigger out-of-memory or an underlying
> > hardware/software failure).
> >
> > I usually get my builds to reboot my system when I build on a loptop. I have
> > not seen this on a tower style work station. You may want to play with the
> > BB_NUMBER_THREADS=# and PARALLEL_MAKE = "-j #" settings in your
> > local.conf.
> >
> > - armin
> > >
> > > Assuming the X session is ending is there anything in your
> > > ~/.xsession-errors or /var/log/Xorg.*.log?
> > >
> > > Cheers,
> > > Paul
> > >
> > > On Friday, 24 March 2017 5:58:24 AM NZDT Greg Wilson-Lindberg wrote:
> > >> Hi Paul,
> > >>
> > >> I looked in the logs from the failure yesterday and couldn't find
> > >> anything, so I restarted the build and it ran for about another 1000
> > >> steps before crashing again. I still can't find anything in any of
> > >> the logs, syslog, kern.log, auth.log, etc.
> > >>
> > >> Cheers,
> > >> Greg
> > >>
> > >>> -Original Message-
> > >>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com 
> > >>> ]
> > >>> Sent: Thursday, March 23, 2017 2:49 AM
> > >>> To: Greg Wilson-Lindberg  > >>> >
> > >>> Cc: yocto@yoctoproject.org ; akuster808 
> > >>> mailto:akuster...@gmail.com>>
> > >>> Subject: Re: [yocto] Morty 2.2.1 build failure
> > >>>
> > >>> On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg
> > wrote:
> >  I tried it again this morning and it did get past the file not
> >  found error.
> >  But when it gets above step 4000 somewhere it gets an error that
> >  kills not just the yocto build but the full login session. I'm left
> >  staring at the Linux Login screen.
> > >>> Your machine isn't running out of RAM by any chance, triggering the
> > >>> OOM killer? Anything indicative in your system logs?
> > >>>
> > >>> Cheers,
> > >>> Paul
> > >>>
> > >>> --
> > >>>
> > >>> Paul Eggleton
> > >>> Intel Open Source Technology Centre
> > >
> 
> --
> ___
> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] are there any outstanding patches to be applied to BSP Guide?

2017-03-24 Thread Robert P. J. Day 

  i know i was working on some tweaks but can't find if i submitted
any yet. can anyone verify that what's up under "in progress/latest"
is the current version, as git pull'ed from yocto docs? thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] Remove a recipe's do_install_append() function in an append file

2017-03-24 Thread Cody Piersall 
Hello,

I am building zsh from meta-oe layer, and it has a do_install_append()
function defined like this:

do_install_append () {
rm -fr ${D}/usr/share
}

which gets rid of lots lots of useful functionality, like
context-aware autocompletion.  Can a bbappend file get rid of that
function, or do I need to edit the actual recipe? I've attempted
defining an empty do_install_append() { : } but it didn't work.

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

Re: [yocto] Remove a recipe's do_install_append() function in an append file

2017-03-24 Thread Robert P. J. Day 
On Fri, 24 Mar 2017, Cody Piersall wrote:

> Hello,
>
> I am building zsh from meta-oe layer, and it has a do_install_append()
> function defined like this:
>
> do_install_append () {
> rm -fr ${D}/usr/share
> }
>
> which gets rid of lots lots of useful functionality, like
> context-aware autocompletion.  Can a bbappend file get rid of that
> function, or do I need to edit the actual recipe? I've attempted
> defining an empty do_install_append() { : } but it didn't work.

  it might be worth asking why zsh is doing that in the first place.
if one doesn't want all that stuff, *that* is where an append could be
used to remove it. i think zsh removing it by default is
inappropriate.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] Remove a recipe's do_install_append() function in an append file

2017-03-24 Thread Alexander Kanavin 

On 03/24/2017 03:53 PM, Robert P. J. Day wrote:

On Fri, 24 Mar 2017, Cody Piersall wrote:



do_install_append () {
rm -fr ${D}/usr/share
}

which gets rid of lots lots of useful functionality, like
context-aware autocompletion.  Can a bbappend file get rid of that
function, or do I need to edit the actual recipe? I've attempted
defining an empty do_install_append() { : } but it didn't work.


  it might be worth asking why zsh is doing that in the first place.
if one doesn't want all that stuff, *that* is where an append could be
used to remove it. i think zsh removing it by default is
inappropriate.


That's right; it's better to fix the original recipe and send the patch 
so it can be included in meta-oe. What is written in recipes is not some 
kind of Universal Truth; if you see how things could be done better, go 
ahead and do it.


Alex

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

Re: [yocto] Remove a recipe's do_install_append() function in an append file

2017-03-24 Thread Burton, Ross 
On 24 March 2017 at 13:49, Cody Piersall  wrote:

> I am building zsh from meta-oe layer, and it has a do_install_append()
> function defined like this:
>
> do_install_append () {
> rm -fr ${D}/usr/share
> }
>
> which gets rid of lots lots of useful functionality, like
> context-aware autocompletion.  Can a bbappend file get rid of that
> function, or do I need to edit the actual recipe? I've attempted
> defining an empty do_install_append() { : } but it didn't work.
>

Fixing the zsh recipe to have either separate packages or PACKAGECONFIGs
for the useful stuff would be the proper solution, but a really nasty hack
that might work is:

do_install_remove = "rm -rf ${D}/usr/share"

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

Re: [yocto] PHP5 Recipe

2017-03-24 Thread Jussi Kukkonen 
On 24 March 2017 at 12:57, Stefano Zuín  wrote:
>
> Good Morning,
>
> I am trying to use php in a simple poky kernel in a core-image-minimal
image. But I have some problems to get it working. I have also tried using
core-image-full-cmdline image having the same result explained after this.
>
> When I cook the recipe everything is OK. I can find inside the
/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.23-r0/image/ directory
all the necessary files to have php running. but unfortunately, when I run
the emulator with my image I can't find all these files. Just in
/usr/lib/php5/php/ are Structures and XML directories. I have also added in
my conf/local.conf file IMAGE_INSTALL_append=" php".


Hi,

It'll help if you are more specific: which files did you expect to see but
did not?

Alternatively, you can look at the FILES_* variables in the recipe (or
$WORKDIR/packages-split/ directories): It's likely that the files you want
are not in "php" but another package like php-cli or php-cgi.

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

Re: [yocto] [meta-security] master-next rebased?

2017-03-24 Thread akuster808 



On 03/24/2017 01:44 AM, Patrick Ohly wrote:

Hello Armin!

Did you accidentally rebase all of master-next?

looks like it.


The current master-next tip (3b9dd3688b6c725aa0146c91ee1a58c26095e48d)
isn't rooted in the current master
(8b38c93f2387793fb03d082e47723002cf667ae9) anymore:

$ git branch -r --contains origin/master-next
   origin/master-next
$ git log --oneline origin/master..origin/master-next  | wc -l
179
$ git log --oneline origin/master  | wc -l
211

Looking at the content, it seems that only the last two commits in
master-next are actually new ;-}

correcting it now.

thanks.
-armin




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

Re: [yocto] Remove a recipe's do_install_append() function in an append file

2017-03-24 Thread Cody Piersall 
On Fri, Mar 24, 2017 at 8:53 AM, Robert P. J. Day  wrote:
> On Fri, 24 Mar 2017, Cody Piersall wrote:
>> I am building zsh from meta-oe layer, and it has a do_install_append()
>> function defined like this:
>>
>> do_install_append () {
>> rm -fr ${D}/usr/share
>> }
>>
>> which gets rid of lots lots of useful functionality, like
>> context-aware autocompletion.  Can a bbappend file get rid of that
>> function, or do I need to edit the actual recipe? I've attempted
>> defining an empty do_install_append() { : } but it didn't work.
>
>   it might be worth asking why zsh is doing that in the first place.
> if one doesn't want all that stuff, *that* is where an append could be
> used to remove it. i think zsh removing it by default is
> inappropriate.
>
> rday

Good point. I've now posted a patch to the meta-oe mailing list:
http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134575.html

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

[yocto] [meta-security][PATCH][V2] samhain: fix build issues when using musl

2017-03-24 Thread Armin Kuster 
[v2]: Correct musl malloc fix.
remove HAVE_MALLOC_H define; this enables using the included defined mallinfo.

[V1]: Fix c99

x_dnmalloc.c:563:26: error: return type is an incomplete type
| #define public_mALLINFo mallinfo
| ^
| x_dnmalloc.c:1689:17: note: in expansion of macro 'public_mALLINFo'
| struct mallinfo public_mALLINFo() {

and
_dnmalloc.c:5527:17: error: unknown type name 'u_int'
| u_int rnd[(128 - 2*sizeof(struct timeval)) / sizeof(u_int)];
| ^

Signed-off-by: Armin Kuster 
---
 recipes-security/samhain/files/c99_dnmalloc.patch | 18 ++
 recipes-security/samhain/samhain.inc  |  5 +
 2 files changed, 23 insertions(+)
 create mode 100644 recipes-security/samhain/files/c99_dnmalloc.patch

diff --git a/recipes-security/samhain/files/c99_dnmalloc.patch 
b/recipes-security/samhain/files/c99_dnmalloc.patch
new file mode 100644
index 000..2216564
--- /dev/null
+++ b/recipes-security/samhain/files/c99_dnmalloc.patch
@@ -0,0 +1,18 @@
+samhain: musl build fix c99
+
+Upstream-Status: Submitted
+Signed-off-by: Armin Kuster 
+
+Index: samhain-4.2.0/src/dnmalloc.c
+===
+--- samhain-4.2.0.orig/src/dnmalloc.c
 samhain-4.2.0/src/dnmalloc.c
+@@ -5524,7 +5524,7 @@ arc4_stir(void)
+ struct {
+ struct timeval tv1;
+ struct timeval tv2;
+-u_int rnd[(128 - 2*sizeof(struct timeval)) / sizeof(u_int)];
++unsigned char rnd[(128 - 2*sizeof(struct timeval)) / 
sizeof(unsigned char)];
+ } rdat;
+ #if !defined(__FreeBSD__) && !defined(__OpenBSD__) && !defined(__NetBSD__)
+ ssize_t sz = 0;
diff --git a/recipes-security/samhain/samhain.inc 
b/recipes-security/samhain/samhain.inc
index 789150b..d558e6b 100644
--- a/recipes-security/samhain/samhain.inc
+++ b/recipes-security/samhain/samhain.inc
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b"
 SRC_URI = "http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
   file://${INITSCRIPT_NAME}.init \
   file://${INITSCRIPT_NAME}.default \
+   file://c99_dnmalloc.patch \
  "
 
 SRC_URI[md5sum] = "d98a55646b14f9419fcedde909d1bf02"
@@ -75,6 +76,10 @@ do_configure () {
${EXTRA_OECONF}
 }
 
+do_compile_prepend_libc-musl () {
+   sed -i 's/^#define HAVE_MALLOC_H.*//' ${B}/config.h
+}
+
 # Install the init script, it's default file, and the extraneous
 # documentation.
 do_install_append () {
-- 
2.7.4

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

[yocto] [PATCH][yocto-docs] BSP Guide: Numerous aesthetic tweaks/clarifications

2017-03-24 Thread Robert P. J. Day 
* Outside of a title, use "BSP layer", not "BSP Layer"
* Add details about YP reference boards.
* Minor grammatical clarification in places.
* Add  to even single paragraph notes for consistency.

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 4d0ace0..63848ad 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -19,7 +19,7 @@
 

 
-This guide presents information about BSP Layers, defines a 
structure for components
+This guide presents information about BSP layers, defines a 
structure for components
 so that BSPs follow a commonly understood layout, discusses how to 
customize
 a recipe for a BSP, addresses BSP licensing, and provides 
information that
 shows you how to create and manage a
@@ -33,7 +33,7 @@
 
 A BSP consists of a file structure inside a base directory.
 Collectively, you can think of the base directory, its file 
structure,
-and the contents as a BSP Layer.
+and the contents as a BSP layer.
 Although not a strict requirement, layers in the Yocto Project 
use the
 following well-established naming convention:
 
@@ -77,8 +77,9 @@
 meta-yocto-bsp layer is part of the
 shipped poky repository.
 The meta-yocto-bsp layer maintains several
-BSPs such as the Beaglebone, EdgeRouter, and generic versions 
of
-both 32 and 64-bit IA machines.
+Yocto Project "reference" BSPs such as the ARM-based 
Beaglebone,
+MIPS-based Ubiquiti EdgeRouter, PowerPC-based MPC8315E-RDB,
+and generic versions of both 32 and 64-bit IA machines.
 

 
@@ -94,7 +95,7 @@
 
 The layer's base directory
 (meta-bsp_name)
-is the root of the BSP Layer.
+is the root of the BSP layer.
 This root is what you add to the
 BBLAYERS
 variable in the conf/bblayers.conf file 
found in the
@@ -179,7 +180,7 @@
 

 
-Before looking at the common form for the file structure 
inside a BSP Layer,
+Before looking at the common form for the file structure 
inside a BSP layer,
 you should be aware that some requirements do exist in order 
for a BSP to
 be considered compliant with the Yocto Project.
 For that list of requirements, see the
@@ -188,7 +189,7 @@
 

 
-Below is the common form for the file structure inside a BSP 
Layer.
+Below is the common form for the file structure inside a BSP 
layer.
 While you can use this basic form for the standard, realize 
that the actual structures
 for specific BSPs could differ.

@@ -572,7 +573,8 @@
 

 
-To use an include file, you simply include them in the
+To use an include file, you simply 
include or
+require it in the
 machine configuration file.
 For example, the Raspberry Pi BSP
 raspberrypi3.conf contains the
@@ -956,28 +958,28 @@
 Instructions on how to boot 
the BSP build from
 the BSP layer.
 Instructions on how to boot 
the binary images
-contained in the 
binary directory,
+contained in the 
binary/ directory,
 if present.
 Information on any known bugs 
or issues that users
 should know about when either building or 
booting the BSP
 binaries.
 
 README.sources 
File:
-You must include a 
README.sources in the
-
meta-bsp_name directory.
-This file specifies exactly where you can find the 
sources used to
-generate the binary images contained in the
-binary directory, if present.
+If your BSP layer includes a 
binary/ directory
+with at least one binary image, then it must also 
include a top-level
+README.sources file that 
explains exactly
+where you can find the sources used to generate 
those binary images.
 
 Layer Configuration 
File:
-

Re: [yocto] Buildbot / Autobuilder / custom?

2017-03-24 Thread Alain Achkar 
Thanks Joshua! This fix worked.

On Fri, Mar 24, 2017 at 6:44 AM, Joshua Lock 
wrote:

> Hi Alain,
>
> On Thu, 2017-03-23 at 17:40 -0400, Alain Achkar wrote:
>
> I followed http://git.yoctoproject.org/cgit.cgi/
> yocto-autobuilder/tree/README-QUICKSTART
> and got:
>
>
> 
>
> checking controller.cfg
> LOADING CONFIG FILE
> *error while parsing config file:*
> Traceback (most recent call last):
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py",
> line 1187, in unwindGenerator
> return _inlineCallbacks(None, gen, Deferred())
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py",
> line 1045, in _inlineCallbacks
> result = g.send(result)
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/buildbot-0.8.8-py2.7.egg/buildbot/scripts/upgrade_master.py",
> line 169, in upgradeMaster
> master_cfg = loadConfig(config, configFile)
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/buildbot-0.8.8-py2.7.egg/buildbot/scripts/upgrade_master.py",
> line 53, in loadConfig
> config['basedir'], configFileName)
> ---  ---
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/buildbot-0.8.8-py2.7.egg/buildbot/config.py", line 149, in
> loadConfig
> exec f in localDict
>   File "/media/data/yocto-autobuilder/yocto-controller/controller.cfg",
> line 94, in 
> yocto_buildsets.createBuildsets()
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/autobuilder/Autobuilder.py", line 65, in createBuildsets
> self.parseBuildSet(buildset)
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/autobuilder/Autobuilder.py", line 102, in parseBuildSet
> self.parseRepos(buildset)
>   File "/media/data/yocto-autobuilder/lib/python2.7/
> site-packages/autobuilder/Autobuilder.py", line 127, in parseRepos
> if layer.iterkeys().next() not in self.repos:
> *exceptions.AttributeError: 'list' object has no attribute 'iterkeys'*
>
>
> I appear to have left a stray comma in buildset-config.controller/nightly.conf
> which causes the parser to choke. I've fixed this in the master branch of
> yocto-autobuilder: http://git.yoctoproject.org/clean/cgit.cgi/yocto-
> autobuilder/commit/?id=239eeaa1e2cf3a985e75f8b75dedfe704a7d6991
>
>
> You'll need to edit buildset-config/nightly.conf on your local instance
> similarly to remove the comma at the end of the repos list, around line 38.
>
> Thanks for reporting this error!
>
> Joshua
>
> Errors loading configuration:
>   error while parsing config file: 'list' object has no attribute
> 'iterkeys' (traceback in logfile)
>  To start the autobuilder:
>  ./yocto-start-autobuilder 
>
>  To stop the autobuilder:
>  ./yocto-stop-autobuilder 
>
> >0< alain@esxi-ub1 Thu Mar 23 05:34 PM [master !?]
> /media/data/yocto-autobuilder >
>
> Any ideas on how to fix this?
>
> On Mon, Nov 14, 2016 at 1:40 PM, Bill Randle 
> wrote:
>
> Yes, the 2 TB is for everything you might do with an AutoBuilder. The
> actual space used will be closer to your 35 GB, since you're building
> only a single image / work product. People have used BuilBot directly
> for automated builds, but using the AutoBuilder code (which runs
> BuildBot underneath) gives you added flexibility and capability
> without much additional overhead.
>
> -Bill
>
> On Mon, Nov 14, 2016 at 8:13 AM, Alain Achkar 
> wrote:
> > Thanks for your answers! From reading these links, it is still not clear
> to
> > me if this might be overkill for my requirements. AB Cluster Setup talks
> > about "the worker requires 2+ TB to hold all the build temp files and git
> > repos. If build artifacts and a local sstate mirror are included,
> additional
> > worker space is required."
> >
> > Currently, my build only takes 35GB, so I think what these links are
> talking
> > about is how to replicate what the Autobuilder project
> > https://autobuilder.yoctoproject.org/ already does.
> >
> > To clarify, I am not interested in running builds and tests for
> everything
> > that Yocto already builds and tests (i.e. all the processor
> architectures,
> > all the machine types, etc.).  I am interested in running one build for
> one
> > machine type (the Variscite DART-6UL i.MX6UL arm-based processor, for
> which
> > NXP/Freescale and Variscite have provided recipes and layers for).
> >
> > I know that autobuilder includes BuildBot (this is why I specified it in
> > parentheses) but my question remains: do I only install BuildBot and try
> to
> > build my machine type with it, or do I install Autobuilder?
> >
> > On Mon, Nov 14, 2016 at 10:10 AM, Bill Randle 
> wrote:
> >>
> >> Also, be sure to check the Yocto Project wiki pages:
> >> https://wiki.yoctoproject.org/wiki/The_Yocto_Autobuilder
> >> in particular, the AB cluster setup and AB maintenance links. Even
> >> though the one link refers to setting

Re: [yocto] BSP guide: better example for recursive layer structure than meta-intel?

2017-03-24 Thread Trevor Woerner 
Having a repository-of-layers isn't something that is BSP-only, any
layer can be setup in this way. Maybe this explanation should be cut
from the BSP Guide and moved to a more general manual, say reference?
Or maybe removed altogether? I'm not really sure what it adds; how
repositories are stored and organized inside a revision system (or
otherwise) is inconsequential, so long as bblayers.conf is setup
correctly.

The only repository-of-layers of which I'm aware is meta-linaro
(which, I don't think, is strictly a BSP layer).

If I could go back in time, I'd nix the whole "let's prefix every
layer name with 'meta-'". If every layer is 'meta-', the label itself
becomes useless. It would have been much better if every layer were
prefixed with something useful, such as its type (bsp-intel,
distro-arago, sw-browser). That would be meaningful. Then we could
reserve 'meta-' for the cases where we had repositories-of-layers ;-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BSP guide: better example for recursive layer structure than meta-intel?

2017-03-24 Thread Trevor Woerner 
(forgot the obligatory https://xkcd.com/917/)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] rpi-config: waveshare screen support

2017-03-24 Thread Trevor Woerner 
Add support for the Waveshare 1024x600 "C" Rev2.1 7" IPS Capacitive Touch
Screen LCD with HDMI interface:

http://www.waveshare.com/7inch-HDMI-LCD-C.htm
http://www.waveshare.com/wiki/7inch_HDMI_LCD_(C)

This product works "out of the box" with the Raspberry Pi. Simply connect
the provided HDMI and USB cables between the two devices. The touch<=>mouse
integration works automatically.

Tested with a Raspberry Pi 3, with a 32-bit raspberrypi3 build.

Signed-off-by: Trevor Woerner 
---
 README  | 13 ++---
 recipes-bsp/bootfiles/rpi-config_git.bb | 10 ++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/README b/README
index 65a1e5f..c58bc99 100644
--- a/README
+++ b/README
@@ -29,7 +29,8 @@ Contents:
 3.L. Enable SPI bus
 3.M. Enable I2C
 3.N. Enable PiTFT support
-3.O. Enable UART support
+3.O. Misc. display
+3.P. Enable UART support
 4. Extra apps
 4.A. omxplayer
 5. Board Configuration
@@ -241,9 +242,15 @@ List of currently supported models:
 - pitft22
 - pitft28r
 
-3.O. Enable UART
-===
+3.O. Misc. display
+==
+If you would like to use the Waveshare "C" 1024×600, 7 inch Capacitive Touch
+Screen LCD, HDMI interface (http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
+Rev 2.1, please set the following in your local.conf
+WAVESHARE_1024X600_C_2.1 = "1"
 
+3.P. Enable UART
+===
 RaspberryPi 1, 2 and CM will have UART console enabled by default.
 
 RaspberryPi 3 does not have the UART enabled by default because this needs a
diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb 
b/recipes-bsp/bootfiles/rpi-config_git.bb
index 20ec343..8adc938 100644
--- a/recipes-bsp/bootfiles/rpi-config_git.bb
+++ b/recipes-bsp/bootfiles/rpi-config_git.bb
@@ -110,6 +110,16 @@ do_deploy() {
 echo "# Enable VC4 Graphics" >> 
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 echo "dtoverlay=vc4-kms-v3d,${VC4_CMA_SIZE}" >> 
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 fi
+
+# Waveshare "C" 1024x600 7" Rev2.1 IPS capacitive touch 
(http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
+if [ "${WAVESHARE_1024X600_C_2.1}" = "1" ]; then
+echo "# Waveshare \"C\" 1024x600 7\" Rev2.1 IPS capacitive touch 
screen" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo "max_usb_current=1" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo "hdmi_group=2" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo "hdmi_mode=87" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo "hdmi_cvt 1024 600 60 6 0 0 0" >> 
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo "hdmi_drive=1" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+fi
 }
 
 do_deploy_append_raspberrypi3-64() {
-- 
2.12.0.rc1.48.g076c053

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