Re: [yocto] OpenCV with python3

[Khem Raj]

On Thu, Mar 15, 2018 at 10:29 PM, Tim Orling  wrote:
> Ditto for Robert’s comment. Please look at the bitbake manual and understand
> what the syntax means [1].
>
> Also,  “python-foo” means the python2 version. The default PACKAGECONFIG [2]
> for opencv builds for python3. You need “python3-opencv”.
>
> Finally, I would encourage you to use CORE_IMAGE_EXTRA_INSTALL [3] rather
> than IMAGE_INSTALL in the local.conf context.
>

FYI This suggestion is fine, however it is not sufficient. There is an
inherent assumption that image
is inheriting core-image which is implied and not explicitly
mentioned. many users do not inherit
core-image hence this suggestion will be moot for them.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to get mysqy/mariadb to start on powerup.

[Greg Wilson-Lindberg]

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Friday, March 16, 2018 02:51 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> 
> On Fri, Mar 16, 2018 at 2:22 PM, Greg Wilson-Lindberg 
> wrote:
> >> -Original Message-
> >> From: Khem Raj [mailto:raj.k...@gmail.com]
> >> Sent: Friday, March 16, 2018 02:16 PM
> >> To: Greg Wilson-Lindberg 
> >> Cc: yocto@yoctoproject.org
> >> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> >>
> >> On Fri, Mar 16, 2018 at 2:10 PM, Greg Wilson-Lindberg
> >> 
> >> wrote:
> >> >> -Original Message-
> >> >> From: Khem Raj [mailto:raj.k...@gmail.com]
> >> >> Sent: Friday, March 16, 2018 11:55 AM
> >> >> To: Greg Wilson-Lindberg 
> >> >> Cc: yocto@yoctoproject.org
> >> >> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> >> >>
> > 
> > 
> > 
> >> >
> >> > I've run journalctl on both install_db.service & mysqld.service.
> >> > mysqld comes
> >> back with no entries. install_db comes back with a line each for
> >> Starting and Started Install MySQL Community Server Database.
> >> >
> >> > systemctl status returns exited success for install_db, for mysqld it 
> >> > reports
> Active:
> >> inactive (dead).
> >> >
> >> > systemctl list-unit-files shows install_db as enabled and mysqld as 
> >> > disabled.
> >> >
> >> > I was able to start mysqld with systemctl start and it showed
> >> > running with
> >> systemctl status & ps. But it did not restart after a reboot.
> >>
> >> can you try
> >>
> >> systemctl enable mysqld
> >>
> >> this should enable it to start on boot.
> >
> > That did create a link and it started on reboot.
> >
> 
> OK thats expected see ./meta-oe/recipes-dbs/mysql/mariadb.inc
> 
> SYSTEMD_PACKAGES = "${PN}-server ${PN}-setupdb"
> SYSTEMD_SERVICE_${PN}-server = "mysqld.service"
> SYSTEMD_AUTO_ENABLE_${PN}-server ?= "disable"
> 
> its disabled on install. you can set it to be enabled via a bbappend in your 
> layer

So it seems that I should do a .bbappend with it enabled then.
Thanks,
Greg


> 
> > I take it that something is happening in install_db and among other things 
> > that link
> is not getting created?
> 
> its calling
> 
> mysql-systemd-start pre
> 
> but it depends on mysqld.service so I wonder if it was not working because
> mysqld.service was disabled so may be now it works
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] best way to use sudo for a long running background process

[Davis Roman]

hello,

I have a daemon called powermanager running as the non-root user, power.

In /etc/sudoers.d/power, I have the following:
power ALL=(ALL) NOPASSWD: ALL

I know that the above statement essentially gives the powermanager
process root privileges
however, in the future, I'd like to have the option to enforce certain
commands/files not be used, if needed.
My understanding is that the sudoers file would be the place to place
these rules.
( ie: disable ability to open file /dev/foobar )

Therefore on startup, I configured my systemd service file to run as
the power user however I'm trying to figure out which is better:

1. launch this process as 'sudo powermanager'

or

2.  launch my process as just 'powermanager' and let the process deal
with invoking sudo when it needs to open files in /dev/


Any feedback would be greatly appreciated.

Thank you,

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

Re: [yocto] How to get mysqy/mariadb to start on powerup.

[Khem Raj]

On Fri, Mar 16, 2018 at 2:22 PM, Greg Wilson-Lindberg
 wrote:
>> -Original Message-
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>> Sent: Friday, March 16, 2018 02:16 PM
>> To: Greg Wilson-Lindberg 
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>>
>> On Fri, Mar 16, 2018 at 2:10 PM, Greg Wilson-Lindberg 
>> wrote:
>> >> -Original Message-
>> >> From: Khem Raj [mailto:raj.k...@gmail.com]
>> >> Sent: Friday, March 16, 2018 11:55 AM
>> >> To: Greg Wilson-Lindberg 
>> >> Cc: yocto@yoctoproject.org
>> >> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>> >>
> 
> 
> 
>> >
>> > I've run journalctl on both install_db.service & mysqld.service. mysqld 
>> > comes
>> back with no entries. install_db comes back with a line each for Starting 
>> and Started
>> Install MySQL Community Server Database.
>> >
>> > systemctl status returns exited success for install_db, for mysqld it 
>> > reports Active:
>> inactive (dead).
>> >
>> > systemctl list-unit-files shows install_db as enabled and mysqld as 
>> > disabled.
>> >
>> > I was able to start mysqld with systemctl start and it showed running with
>> systemctl status & ps. But it did not restart after a reboot.
>>
>> can you try
>>
>> systemctl enable mysqld
>>
>> this should enable it to start on boot.
>
> That did create a link and it started on reboot.
>

OK thats expected see ./meta-oe/recipes-dbs/mysql/mariadb.inc

SYSTEMD_PACKAGES = "${PN}-server ${PN}-setupdb"
SYSTEMD_SERVICE_${PN}-server = "mysqld.service"
SYSTEMD_AUTO_ENABLE_${PN}-server ?= "disable"

its disabled on install. you can set it to be enabled via a bbappend
in your layer

> I take it that something is happening in install_db and among other things 
> that link is not getting created?

its calling

mysql-systemd-start pre

but it depends on mysqld.service so I wonder if it was not working
because mysqld.service was disabled
so may be now it works
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] scipy recipe

[Giordon Stark]

Seems like the SRC_URI isn't correct. I don't see an obvious place to get
tarballs for scipy except from github (and I know that tends to not be
reliable but...)

https://github.com/scipy/scipy/archive/v1.0.0.tar.gz

Giordon

On Fri, Mar 16, 2018 at 11:51 AM Peter Balazovic 
wrote:

> per using recipe https://github.com/scipy/scipy/issues/8226
>
>
> SUMMARY = "Scientific Library for Python"
> SECTION = "devel/python"
> HOMEPAGE = "https://pypi.python.org/pypi/scipy;
>
> LICENSE = "BSD-3-Clause"
> LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=d0db8f4148a3d5534cfb93be78f9287c"
>
> PYPI_PACKAGE="scipy"
>
> SRC_URI[md5sum] = "53fa34bd3733a9a4216842b6000f7316"
> SRC_URI[sha256sum] = 
> "87ea1f11a0e9ec08c264dc64551d501fa307289460705f6fccd84cbfc7926d10"
>
> inherit pypi setuptools distutils
>
> RDEPENDS_${PN} += "python-core python-numpy-native python-distutils"
> DEPENDS += "python-numpy"
>
>
> I am getting error to fetch scipy do_fetch error
>
>
> WARNING: scipy-1.0-r0 do_fetch: Failed to fetch URL
> https://files.pythonhosted.org/packages/source/s/scipy/scipy-1.0.tar.gz,
> attempting MIRRORS if available
> ERROR: scipy-1.0-r0 do_fetch: Fetcher failure: Fetch command export
> DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-idNNJsmT3C"; export
> SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export ftp_proxy=
> --progress=dot -v failed with exit code 8, output:
> --2018-03-16 17:43:34--
> https://files.pythonhosted.org/packages/source/s/scipy/scipy-1.0.tar.gz
> Resolving files.pythonhosted.org (files.pythonhosted.org)...
> 151.101.17.63, 2a04:4e42:4::319
> Connecting to files.pythonhosted.org 
> (files.pythonhosted.org)|151.101.17.63|:443...
> connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2018-03-16 17:43:35 ERROR 404: Not Found.
>
> Any help?
>
>
> On Thu, Mar 15, 2018 at 9:35 PM, Randy MacLeod <
> randy.macl...@windriver.com> wrote:
>
>> On 2018-03-15 01:56 PM, Peter Balazovic wrote:
>>
>>> Hello all,
>>>
>>> I wonder if there is scipy recipe available?
>>>
>>
>> Not yet:
>>
>> https://layers.openembedded.org/layerindex/branch/master/recipes/?q=scipy
>>
>> It appears to be blocked by:
>>https://github.com/scipy/scipy/issues/8226
>> but apparently that's a bitbake issue, not a spip one.
>> Care to take a look?
>>
>>
>>> Thanks.
>>>
>>>
>>>
>>
>> --
>> # Randy MacLeod.  WR Linux
>> # Wind River an Intel Company
>>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
Giordon Stark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to get mysqy/mariadb to start on powerup.

[Greg Wilson-Lindberg]

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Friday, March 16, 2018 02:16 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> 
> On Fri, Mar 16, 2018 at 2:10 PM, Greg Wilson-Lindberg 
> wrote:
> >> -Original Message-
> >> From: Khem Raj [mailto:raj.k...@gmail.com]
> >> Sent: Friday, March 16, 2018 11:55 AM
> >> To: Greg Wilson-Lindberg 
> >> Cc: yocto@yoctoproject.org
> >> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> >>



> >
> > I've run journalctl on both install_db.service & mysqld.service. mysqld 
> > comes
> back with no entries. install_db comes back with a line each for Starting and 
> Started
> Install MySQL Community Server Database.
> >
> > systemctl status returns exited success for install_db, for mysqld it 
> > reports Active:
> inactive (dead).
> >
> > systemctl list-unit-files shows install_db as enabled and mysqld as 
> > disabled.
> >
> > I was able to start mysqld with systemctl start and it showed running with
> systemctl status & ps. But it did not restart after a reboot.
> 
> can you try
> 
> systemctl enable mysqld
> 
> this should enable it to start on boot.

That did create a link and it started on reboot.

I take it that something is happening in install_db and among other things that 
link is not getting created?

Greg
> 
> >
> > If there is anything else that I can do to help understand what is going on 
> > please let
> me know.
> >
> > Greg
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to get mysqy/mariadb to start on powerup.

[Khem Raj]

On Fri, Mar 16, 2018 at 2:10 PM, Greg Wilson-Lindberg
 wrote:
>> -Original Message-
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>> Sent: Friday, March 16, 2018 11:55 AM
>> To: Greg Wilson-Lindberg 
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>>
>> On Fri, Mar 16, 2018 at 8:58 AM, Greg Wilson-Lindberg 
>> wrote:
>> >> From: Greg Wilson-Lindberg
>> >> Sent: Thursday, March 15, 2018 02:16 PM
>> >> To: Khem Raj 
>> >> Cc: yocto@yoctoproject.org
>> >> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>> >
>> >>
>> >
>> >> > From: Khem Raj 
>> >
>> >> > Sent: Thursday, March 15, 2018 1:54 PM
>> >> > To: Greg Wilson-Lindberg
>> >> > Cc: yocto@yoctoproject.org
>> >> > Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>> >
>> >> >
>> >
>> >> > > On Thu, Mar 15, 2018 at 1:38 PM, Greg Wilson-Lindberg
>> >> >  wrote:
>> >> > > I'm building an RPi3 system that is going to use mysql/mariadb.
>> >> > > I've got everything installed, but mysqld is not starting.
>> >> > > install_db.service does run on startup, but the mysqld.service
>> >> > > file never gets triggered.
>> >> > >
>> >> > >
>> >> > > Is there something that I'm missing to get it to run? I've search
>> >> > > online, but can't find anything that pertains to yocto.
>> >> > >
>> >> >
>> >> > poke on the system with systemctl/journalctl to see whats going on
>> >
>> >>
>> >
>> >> journalctl -u mysqld.service says no entries
>> >
>> >> systemctl status mysqld.service shows:
>> >
>> >>Loaded: loaded (/lib/systemd/system/mysqld.service; disabled;
>> >> vendor
>> >> preset: enabled)
>> >
>> >>Active: inactive (dead)
>> >
>> >>
>> >
>> >> I've rebooted the system a couple of times to see if install_db
>> >> needed to be run before mysql would run, no luck.
>> >
>> >>
>> >
>> > It's seems that maybe I need to add a bit about my understanding of
>> > the yocto system. I was assuming that if I included mysql in the
>> > build, that it would be started when the system powered up. If mysql
>> > is not normally started automatically that I can do what is necessary
>> > to start it, I just thought that I shouldn't need to do anything.
>>
>> Yes you are right. We try to do runtime testing as much as possible and you 
>> will see
>> more and more focus on runtime testing in coming days and months. So far we
>> have had lot of build related features and stability problems to work on so 
>> chances
>> of runtime bugs are still a bit higher. You can help in fixing this issue if 
>> you can root
>> cause it. eg. check in system logs using journalctl for possible causes of 
>> this service
>> not starting up. Often times you will get a decent hint and we can help as 
>> well on
>> that information
>
> I've run journalctl on both install_db.service & mysqld.service. mysqld comes 
> back with no entries. install_db comes back with a line each for Starting and 
> Started Install MySQL Community Server Database.
>
> systemctl status returns exited success for install_db, for mysqld it reports 
> Active: inactive (dead).
>
> systemctl list-unit-files shows install_db as enabled and mysqld as disabled.
>
> I was able to start mysqld with systemctl start and it showed running with 
> systemctl status & ps. But it did not restart after a reboot.

can you try

systemctl enable mysqld

this should enable it to start on boot.

>
> If there is anything else that I can do to help understand what is going on 
> please let me know.
>
> Greg
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to get mysqy/mariadb to start on powerup.

[Greg Wilson-Lindberg]

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Friday, March 16, 2018 11:55 AM
> To: Greg Wilson-Lindberg 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> 
> On Fri, Mar 16, 2018 at 8:58 AM, Greg Wilson-Lindberg 
> wrote:
> >> From: Greg Wilson-Lindberg
> >> Sent: Thursday, March 15, 2018 02:16 PM
> >> To: Khem Raj 
> >> Cc: yocto@yoctoproject.org
> >> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> >
> >>
> >
> >> > From: Khem Raj 
> >
> >> > Sent: Thursday, March 15, 2018 1:54 PM
> >> > To: Greg Wilson-Lindberg
> >> > Cc: yocto@yoctoproject.org
> >> > Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> >
> >> >
> >
> >> > > On Thu, Mar 15, 2018 at 1:38 PM, Greg Wilson-Lindberg
> >> >  wrote:
> >> > > I'm building an RPi3 system that is going to use mysql/mariadb.
> >> > > I've got everything installed, but mysqld is not starting.
> >> > > install_db.service does run on startup, but the mysqld.service
> >> > > file never gets triggered.
> >> > >
> >> > >
> >> > > Is there something that I'm missing to get it to run? I've search
> >> > > online, but can't find anything that pertains to yocto.
> >> > >
> >> >
> >> > poke on the system with systemctl/journalctl to see whats going on
> >
> >>
> >
> >> journalctl -u mysqld.service says no entries
> >
> >> systemctl status mysqld.service shows:
> >
> >>Loaded: loaded (/lib/systemd/system/mysqld.service; disabled;
> >> vendor
> >> preset: enabled)
> >
> >>Active: inactive (dead)
> >
> >>
> >
> >> I've rebooted the system a couple of times to see if install_db
> >> needed to be run before mysql would run, no luck.
> >
> >>
> >
> > It's seems that maybe I need to add a bit about my understanding of
> > the yocto system. I was assuming that if I included mysql in the
> > build, that it would be started when the system powered up. If mysql
> > is not normally started automatically that I can do what is necessary
> > to start it, I just thought that I shouldn't need to do anything.
> 
> Yes you are right. We try to do runtime testing as much as possible and you 
> will see
> more and more focus on runtime testing in coming days and months. So far we
> have had lot of build related features and stability problems to work on so 
> chances
> of runtime bugs are still a bit higher. You can help in fixing this issue if 
> you can root
> cause it. eg. check in system logs using journalctl for possible causes of 
> this service
> not starting up. Often times you will get a decent hint and we can help as 
> well on
> that information

I've run journalctl on both install_db.service & mysqld.service. mysqld comes 
back with no entries. install_db comes back with a line each for Starting and 
Started Install MySQL Community Server Database.

systemctl status returns exited success for install_db, for mysqld it reports 
Active: inactive (dead).

systemctl list-unit-files shows install_db as enabled and mysqld as disabled.

I was able to start mysqld with systemctl start and it showed running with 
systemctl status & ps. But it did not restart after a reboot.

If there is anything else that I can do to help understand what is going on 
please let me know.

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

[yocto] [meta-gplv2][PATCH] nettle: refresh the patches

[Martin Jansa]

From: Martin Jansa 

* fixes:
WARNING: nettle-2.7.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly 
applied patches.
The context lines in the patches can be updated with devtool:

devtool modify 
devtool finish --force-patch-refresh  

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch Add-target-to-only-build-tests-not-run-them.patch
patching file Makefile.in
Hunk #1 succeeded at 53 (offset -2 lines).
patching file testsuite/Makefile.in
Hunk #1 succeeded at 105 with fuzz 2 (offset -11 lines).

Now at patch Add-target-to-only-build-tests-not-run-them.patch

Signed-off-by: Martin Jansa 
---
 ...d-target-to-only-build-tests-not-run-them.patch | 18 +++
 .../nettle/nettle-2.7.1/CVE-2015-8803_8805.patch   | 59 +-
 .../nettle/nettle-2.7.1/CVE-2015-8804.patch| 26 +++---
 ...k-header-files-of-openssl-only-if-enable_.patch |  6 +--
 4 files changed, 63 insertions(+), 46 deletions(-)

diff --git 
a/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
 
b/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
index 23da777..af77aec 100644
--- 
a/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
+++ 
b/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
@@ -1,4 +1,4 @@
-From 46edf01cc98db9f9feec984897836dfdd26bdc8d Mon Sep 17 00:00:00 2001
+From 9225dfb91b6b5617cf2dff32d370cf027237d4c8 Mon Sep 17 00:00:00 2001
 From: Jussi Kukkonen 
 Date: Wed, 12 Aug 2015 23:27:27 +0300
 Subject: [PATCH] Add target to only build tests (not run them)
@@ -9,16 +9,17 @@ installable tests: It's useful for us already as is.
 Upstream-Status: Inappropriate [not a complete solution]
 
 Signed-off-by: Jussi Kukkonen 
+
 ---
  Makefile.in   | 3 +++
  testsuite/Makefile.in | 2 ++
  2 files changed, 5 insertions(+)
 
 diff --git a/Makefile.in b/Makefile.in
-index 08efb7d..7909342 100644
+index 2c25007..ef21b1b 100644
 --- a/Makefile.in
 +++ b/Makefile.in
-@@ -55,6 +55,9 @@ clean distclean mostlyclean maintainer-clean tags:
+@@ -53,6 +53,9 @@ clean distclean mostlyclean maintainer-clean tags:
  echo "Making $@ in $$d" ; (cd $$d && $(MAKE) $@); done
$(MAKE) $@-here
  
@@ -29,18 +30,15 @@ index 08efb7d..7909342 100644
true
  
 diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in
-index 6bc1907..bb65bf0 100644
+index 91f6e2a..52f5c29 100644
 --- a/testsuite/Makefile.in
 +++ b/testsuite/Makefile.in
-@@ -116,6 +116,8 @@ $(TARGETS) $(EXTRA_TARGETS): testutils.$(OBJEXT) 
../nettle-internal.$(OBJEXT) \
- # data.
- VALGRIND = valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes 
@IF_ASM@ --partial-loads-ok=yes
+@@ -105,6 +105,8 @@ $(TARGETS) $(EXTRA_TARGETS): testutils.$(OBJEXT) 
../nettle-internal.$(OBJEXT) \
+ 
+ VALGRIND = valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes
  
 +buildtest: $(TS_ALL)
 +
  # The PATH update is for locating dlls on w*ndows.
  check: $(TS_ALL)
LD_LIBRARY_PATH=../.lib PATH="../.lib:$$PATH" srcdir="$(srcdir)" \
--- 
-2.1.4
-
diff --git a/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch 
b/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch
index a956f42..988f39e 100644
--- a/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch
+++ b/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch
@@ -1,3 +1,8 @@
+From f21b9f7b21067fa3630607cdc1663141b2735ae5 Mon Sep 17 00:00:00 2001
+From: Armin Kuster 
+Date: Thu, 2 Mar 2017 12:24:31 +
+Subject: [PATCH] Create meta-gplv2 from files from OE-Core
+
 Upstream-Status: Backport
 
https://git.lysator.liu.se/nettle/nettle/commit/c71d2c9d20eeebb985e3872e4550137209e3ce4d
 
@@ -8,14 +13,36 @@ Same fix for both.
 
 Signed-off-by: Armin Kuster 
 
-Index: nettle-2.7.1/ecc-256.c
-===
 nettle-2.7.1.orig/ecc-256.c
-+++ nettle-2.7.1/ecc-256.c
-@@ -96,9 +96,19 @@ ecc_256_modp (const struct ecc_curve *ec
+---
+ ChangeLog |  6 ++
+ ecc-256.c | 23 ++-
+ 2 files changed, 24 insertions(+), 5 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 7b7854d..abdd974 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,9 @@
++2015-12-10  Niels Möller  
++
++   * ecc-256.c (ecc_256_modp): Fixed carry propagation bug. Problem
++   reported by Hanno Böck.
++   (ecc_256_modq): Fixed another 

Re: [yocto] scipy recipe

[Peter Balazovic]

openblas - no success yet

NOTE: Executing RunQueue Tasks
ERROR: openblas-0.2.19-r0 do_compile: oe_runmake failed
ERROR: openblas-0.2.19-r0 do_compile: Function failed: do_compile (log file
is located at /openblas/0.2.19-r0/temp/log.do_compile.9671)
ERROR: Logfile of failure stored in:
/openblas/0.2.19-r0/temp/log.do_compile.9671

| ERROR: oe_runmake failed
| aarch64-poky-linux-gcc: error: ../libopenblas_armv8p-r0.2.19.a: No such
file or directory
| aarch64-poky-linux-gcc: error: unrecognized command line option '-ru';
did you mean '-r'?
| ../Makefile.tail:40: recipe for target 'libs' failed
| make[1]: *** [libs] Error 1
| make[1]: Leaving directory '/openblas/0.2.19-r0/OpenBLAS-0.2.19/interface'
| Makefile:133: recipe for target 'libs' failed
| make: *** [libs] Error 1
| ERROR: Function failed: do_compile (log file is located at
/openblas/0.2.19-r0/temp/log.do_compile.9671)
ERROR: Task
(/sources/meta-openembedded/meta-python/recipes-devtools/python/openblas_0.2.19.bb:do_compile)
failed with exit code '1'



On Fri, Mar 16, 2018 at 7:33 PM, Giordon Stark  wrote:

> OpenBLAS is here: http://layers.openembedded.org/layerindex/recipe/6/
>
> G
>
> On Fri, Mar 16, 2018 at 1:30 PM Philip Balister 
> wrote:
>
>> You'll get to Atlas soon, and that is another source of pain :)
>>
>> Philip
>>
>> On 03/16/2018 11:26 AM, Peter Balazovic wrote:
>> > Seems OpenBLAS is missing, is there recipe for it?
>> >
>> > ERROR: scipy-1.0.0-r0 do_compile: python setup.py build execution
>> failed.
>> > ERROR: scipy-1.0.0-r0 do_compile: Function failed: do_compile (log file
>> is
>> > located at /log.do_compile.8708)
>> > ERROR: Logfile of failure stored in: /1.0.0-r0/temp/log.do_compile.8708
>> > Log data follows:
>> > | DEBUG: Executing shell function do_compile
>> > | ERROR: python setup.py build execution failed.
>> > | /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
>> > distribution option: 'python_requires'
>> > |   warnings.warn(msg)
>> > | lapack_opt_info:
>> > | openblas_lapack_info:
>> > |   libraries openblas not found in ['/usr/lib']
>> > |   NOT AVAILABLE
>> > |
>> > | lapack_mkl_info:
>> > | mkl_info:
>> > |   libraries mkl,vml,guide not found in ['/usr/lib']
>> > |   NOT AVAILABLE
>> > |
>> > |   NOT AVAILABLE
>> > |
>> > | atlas_3_10_threads_info:
>> > | Setting PTATLAS=ATLAS
>> > |   libraries tatlas,tatlas not found in /usr/lib
>> > |   libraries lapack_atlas not found in /usr/lib
>> > | 
>> > |   NOT AVAILABLE
>> > |
>> > | atlas_3_10_info:
>> > |   libraries satlas,satlas not found in /usr/lib
>> > |   libraries lapack_atlas not found in /usr/lib
>> > | 
>> > |   NOT AVAILABLE
>> > |
>> > | atlas_threads_info:
>> > | Setting PTATLAS=ATLAS
>> > |   libraries ptf77blas,ptcblas,atlas not found in /usr/lib
>> > |   libraries lapack_atlas not found in /usr/lib
>> > | 
>> > |   NOT AVAILABLE
>> > |
>> > | atlas_info:
>> > |   libraries f77blas,cblas,atlas not found in /usr/lib
>> > |   libraries lapack_atlas not found in /usr/lib
>> > | 
>> > |   NOT AVAILABLE
>> > |
>> > |  /usr/lib/python2.7/site-packages/numpy/distutils/
>> system_info.py:1510:
>> > UserWarning:
>> > | Atlas (http://math-atlas.sourceforge.net/) libraries not found.
>> > | Directories to search for the libraries can be specified in the
>> > | numpy/distutils/site.cfg file (section [atlas]) or by setting
>> > | the ATLAS environment variable.
>> > |   warnings.warn(AtlasNotFoundError.__doc__)
>> > | lapack_info:
>> > |   libraries lapack not found in ['/usr/lib']
>> > |   NOT AVAILABLE
>> > |
>> > | /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1521:
>> > UserWarning:
>> > | Lapack (http://www.netlib.org/lapack/) libraries not found.
>> > | Directories to search for the libraries can be specified in the
>> > | numpy/distutils/site.cfg file (section [lapack]) or by setting
>> > | the LAPACK environment variable.
>> > |   warnings.warn(LapackNotFoundError.__doc__)
>> > | lapack_src_info:
>> > |   NOT AVAILABLE
>> > |
>> > | /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1524:
>> > UserWarning:
>> > | Lapack (http://www.netlib.org/lapack/) sources not found.
>> > | Directories to search for the sources can be specified in the
>> > | numpy/distutils/site.cfg file (section [lapack_src]) or by setting
>> > | the LAPACK_SRC environment variable.
>> > |   warnings.warn(LapackSrcNotFoundError.__doc__)
>> > |   NOT AVAILABLE
>> > |
>> > | Running from scipy source directory.
>> > | Traceback (most recent call last):
>> > |   File "setup.py", line 418, in 
>> > | setup_package()
>> > |   File "setup.py", line 414, in setup_package
>> > | setup(**metadata)
>> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/core.py",
>> line
>> > 135, in setup
>> > | config = configuration()
>> > |   File "setup.py", line 336, in configuration
>> > | config.add_subpackage('scipy')
>> > |   File 

Re: [yocto] How can I check "shared-library-to-package mapping"

[Khem Raj]

On Fri, Mar 16, 2018 at 11:05 AM, ikjn  wrote:
>
> On Thu, Mar 15, 2018 at 11:37 AM, Khem Raj  wrote:
>>
>>
>> On Wed, Mar 14, 2018 at 8:50 AM ikjn  wrote:
>>>
>>> Hi.
>>>
>>> My recipe 'A' installs pre-built shared libraries, but I get file_rdeps
>>> error on
>>> 'B' recipe's package_qa task, which has runtime dependency on A's so
>>> files.
>>
>>
>> Yes however it depends on SONAME being added to the shared objects when
>> they are linked otherwise shlibs code is not able to auto detect the
>> dependency
>
>
> Thank you, now I got it!
> I thought only file name is used for run time dependency matching between
> packages.
> SONAME matching is also executed in build time dependency check when
> DEPENDS_xxx is given?
>

its primarily for runtime dependency checks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to get mysqy/mariadb to start on powerup.

[Khem Raj]

On Fri, Mar 16, 2018 at 8:58 AM, Greg Wilson-Lindberg
 wrote:
>> From: Greg Wilson-Lindberg
>> Sent: Thursday, March 15, 2018 02:16 PM
>> To: Khem Raj 
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>
>>
>
>> > From: Khem Raj 
>
>> > Sent: Thursday, March 15, 2018 1:54 PM
>> > To: Greg Wilson-Lindberg
>> > Cc: yocto@yoctoproject.org
>> > Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>
>> >
>
>> > > On Thu, Mar 15, 2018 at 1:38 PM, Greg Wilson-Lindberg
>> >  wrote:
>> > > I'm building an RPi3 system that is going to use mysql/mariadb. I've
>> > > got
>> > > everything installed, but mysqld is not starting. install_db.service
>> > > does
>> > > run on startup, but the mysqld.service file never gets triggered.
>> > >
>> > >
>> > > Is there something that I'm missing to get it to run? I've search
>> > > online,
>> > > but can't find anything that pertains to yocto.
>> > >
>> >
>> > poke on the system with systemctl/journalctl to see whats going on
>
>>
>
>> journalctl -u mysqld.service says no entries
>
>> systemctl status mysqld.service shows:
>
>>Loaded: loaded (/lib/systemd/system/mysqld.service; disabled; vendor
>> preset: enabled)
>
>>Active: inactive (dead)
>
>>
>
>> I've rebooted the system a couple of times to see if install_db needed to
>> be run before mysql would run, no luck.
>
>>
>
> It's seems that maybe I need to add a bit about my understanding of the
> yocto system. I was assuming that if I included mysql in the build, that it
> would be started when the system powered up. If mysql is not normally
> started automatically that I can do what is necessary to start it, I just
> thought that I shouldn't need to do anything.

Yes you are right. We try to do runtime testing as much as possible and you will
see more and more focus on runtime testing in coming days and months. So far
we have had lot of build related features and stability problems to
work on so chances
of runtime bugs are still a bit higher. You can help in fixing this
issue if you can root
cause it. eg. check in system logs using journalctl for possible
causes of this service
not starting up. Often times you will get a decent hint and we can
help as well on
that information
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] scipy recipe

[Giordon Stark]

OpenBLAS is here: http://layers.openembedded.org/layerindex/recipe/6/

G

On Fri, Mar 16, 2018 at 1:30 PM Philip Balister  wrote:

> You'll get to Atlas soon, and that is another source of pain :)
>
> Philip
>
> On 03/16/2018 11:26 AM, Peter Balazovic wrote:
> > Seems OpenBLAS is missing, is there recipe for it?
> >
> > ERROR: scipy-1.0.0-r0 do_compile: python setup.py build execution failed.
> > ERROR: scipy-1.0.0-r0 do_compile: Function failed: do_compile (log file
> is
> > located at /log.do_compile.8708)
> > ERROR: Logfile of failure stored in: /1.0.0-r0/temp/log.do_compile.8708
> > Log data follows:
> > | DEBUG: Executing shell function do_compile
> > | ERROR: python setup.py build execution failed.
> > | /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
> > distribution option: 'python_requires'
> > |   warnings.warn(msg)
> > | lapack_opt_info:
> > | openblas_lapack_info:
> > |   libraries openblas not found in ['/usr/lib']
> > |   NOT AVAILABLE
> > |
> > | lapack_mkl_info:
> > | mkl_info:
> > |   libraries mkl,vml,guide not found in ['/usr/lib']
> > |   NOT AVAILABLE
> > |
> > |   NOT AVAILABLE
> > |
> > | atlas_3_10_threads_info:
> > | Setting PTATLAS=ATLAS
> > |   libraries tatlas,tatlas not found in /usr/lib
> > |   libraries lapack_atlas not found in /usr/lib
> > | 
> > |   NOT AVAILABLE
> > |
> > | atlas_3_10_info:
> > |   libraries satlas,satlas not found in /usr/lib
> > |   libraries lapack_atlas not found in /usr/lib
> > | 
> > |   NOT AVAILABLE
> > |
> > | atlas_threads_info:
> > | Setting PTATLAS=ATLAS
> > |   libraries ptf77blas,ptcblas,atlas not found in /usr/lib
> > |   libraries lapack_atlas not found in /usr/lib
> > | 
> > |   NOT AVAILABLE
> > |
> > | atlas_info:
> > |   libraries f77blas,cblas,atlas not found in /usr/lib
> > |   libraries lapack_atlas not found in /usr/lib
> > | 
> > |   NOT AVAILABLE
> > |
> > |  /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1510:
> > UserWarning:
> > | Atlas (http://math-atlas.sourceforge.net/) libraries not found.
> > | Directories to search for the libraries can be specified in the
> > | numpy/distutils/site.cfg file (section [atlas]) or by setting
> > | the ATLAS environment variable.
> > |   warnings.warn(AtlasNotFoundError.__doc__)
> > | lapack_info:
> > |   libraries lapack not found in ['/usr/lib']
> > |   NOT AVAILABLE
> > |
> > | /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1521:
> > UserWarning:
> > | Lapack (http://www.netlib.org/lapack/) libraries not found.
> > | Directories to search for the libraries can be specified in the
> > | numpy/distutils/site.cfg file (section [lapack]) or by setting
> > | the LAPACK environment variable.
> > |   warnings.warn(LapackNotFoundError.__doc__)
> > | lapack_src_info:
> > |   NOT AVAILABLE
> > |
> > | /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1524:
> > UserWarning:
> > | Lapack (http://www.netlib.org/lapack/) sources not found.
> > | Directories to search for the sources can be specified in the
> > | numpy/distutils/site.cfg file (section [lapack_src]) or by setting
> > | the LAPACK_SRC environment variable.
> > |   warnings.warn(LapackSrcNotFoundError.__doc__)
> > |   NOT AVAILABLE
> > |
> > | Running from scipy source directory.
> > | Traceback (most recent call last):
> > |   File "setup.py", line 418, in 
> > | setup_package()
> > |   File "setup.py", line 414, in setup_package
> > | setup(**metadata)
> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/core.py", line
> > 135, in setup
> > | config = configuration()
> > |   File "setup.py", line 336, in configuration
> > | config.add_subpackage('scipy')
> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> > line 1003, in add_subpackage
> > | caller_level = 2)
> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> > line 972, in get_subpackage
> > | caller_level = caller_level + 1)
> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> > line 909, in _get_configuration_from_setup_py
> > | config = setup_module.configuration(*args)
> > |   File "scipy/setup.py", line 15, in configuration
> > | config.add_subpackage('linalg')
> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> > line 1003, in add_subpackage
> > | caller_level = 2)
> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> > line 972, in get_subpackage
> > | caller_level = caller_level + 1)
> > |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> > line 909, in _get_configuration_from_setup_py
> > | config = setup_module.configuration(*args)
> > |   File "scipy/linalg/setup.py", line 19, in configuration
> > | raise NotFoundError('no lapack/blas resources found')
> > | numpy.distutils.system_info.NotFoundError: no lapack/blas resources

Re: [yocto] scipy recipe

[Philip Balister]

You'll get to Atlas soon, and that is another source of pain :)

Philip

On 03/16/2018 11:26 AM, Peter Balazovic wrote:
> Seems OpenBLAS is missing, is there recipe for it?
> 
> ERROR: scipy-1.0.0-r0 do_compile: python setup.py build execution failed.
> ERROR: scipy-1.0.0-r0 do_compile: Function failed: do_compile (log file is
> located at /log.do_compile.8708)
> ERROR: Logfile of failure stored in: /1.0.0-r0/temp/log.do_compile.8708
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | ERROR: python setup.py build execution failed.
> | /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
> distribution option: 'python_requires'
> |   warnings.warn(msg)
> | lapack_opt_info:
> | openblas_lapack_info:
> |   libraries openblas not found in ['/usr/lib']
> |   NOT AVAILABLE
> |
> | lapack_mkl_info:
> | mkl_info:
> |   libraries mkl,vml,guide not found in ['/usr/lib']
> |   NOT AVAILABLE
> |
> |   NOT AVAILABLE
> |
> | atlas_3_10_threads_info:
> | Setting PTATLAS=ATLAS
> |   libraries tatlas,tatlas not found in /usr/lib
> |   libraries lapack_atlas not found in /usr/lib
> | 
> |   NOT AVAILABLE
> |
> | atlas_3_10_info:
> |   libraries satlas,satlas not found in /usr/lib
> |   libraries lapack_atlas not found in /usr/lib
> | 
> |   NOT AVAILABLE
> |
> | atlas_threads_info:
> | Setting PTATLAS=ATLAS
> |   libraries ptf77blas,ptcblas,atlas not found in /usr/lib
> |   libraries lapack_atlas not found in /usr/lib
> | 
> |   NOT AVAILABLE
> |
> | atlas_info:
> |   libraries f77blas,cblas,atlas not found in /usr/lib
> |   libraries lapack_atlas not found in /usr/lib
> | 
> |   NOT AVAILABLE
> |
> |  /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1510:
> UserWarning:
> | Atlas (http://math-atlas.sourceforge.net/) libraries not found.
> | Directories to search for the libraries can be specified in the
> | numpy/distutils/site.cfg file (section [atlas]) or by setting
> | the ATLAS environment variable.
> |   warnings.warn(AtlasNotFoundError.__doc__)
> | lapack_info:
> |   libraries lapack not found in ['/usr/lib']
> |   NOT AVAILABLE
> |
> | /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1521:
> UserWarning:
> | Lapack (http://www.netlib.org/lapack/) libraries not found.
> | Directories to search for the libraries can be specified in the
> | numpy/distutils/site.cfg file (section [lapack]) or by setting
> | the LAPACK environment variable.
> |   warnings.warn(LapackNotFoundError.__doc__)
> | lapack_src_info:
> |   NOT AVAILABLE
> |
> | /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1524:
> UserWarning:
> | Lapack (http://www.netlib.org/lapack/) sources not found.
> | Directories to search for the sources can be specified in the
> | numpy/distutils/site.cfg file (section [lapack_src]) or by setting
> | the LAPACK_SRC environment variable.
> |   warnings.warn(LapackSrcNotFoundError.__doc__)
> |   NOT AVAILABLE
> |
> | Running from scipy source directory.
> | Traceback (most recent call last):
> |   File "setup.py", line 418, in 
> | setup_package()
> |   File "setup.py", line 414, in setup_package
> | setup(**metadata)
> |   File "/usr/lib/python2.7/site-packages/numpy/distutils/core.py", line
> 135, in setup
> | config = configuration()
> |   File "setup.py", line 336, in configuration
> | config.add_subpackage('scipy')
> |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> line 1003, in add_subpackage
> | caller_level = 2)
> |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> line 972, in get_subpackage
> | caller_level = caller_level + 1)
> |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> line 909, in _get_configuration_from_setup_py
> | config = setup_module.configuration(*args)
> |   File "scipy/setup.py", line 15, in configuration
> | config.add_subpackage('linalg')
> |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> line 1003, in add_subpackage
> | caller_level = 2)
> |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> line 972, in get_subpackage
> | caller_level = caller_level + 1)
> |   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
> line 909, in _get_configuration_from_setup_py
> | config = setup_module.configuration(*args)
> |   File "scipy/linalg/setup.py", line 19, in configuration
> | raise NotFoundError('no lapack/blas resources found')
> | numpy.distutils.system_info.NotFoundError: no lapack/blas resources found
> | ERROR: Function failed: do_compile (log file is located at
> /scipy/1.0.0-r0/temp/log.do_compile.8708)
> ERROR: Task
> (/sources/meta-openembedded/meta-python/recipes-devtools/python/scipy_1.0.0.bb:do_compile)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 8394 tasks of which 8382 didn't need to be
> rerun and 1 failed.
> 
> 
> On Fri, Mar 16, 2018 at 6:36 PM, 

Re: [yocto] scipy recipe

[Peter Balazovic]

Seems OpenBLAS is missing, is there recipe for it?

ERROR: scipy-1.0.0-r0 do_compile: python setup.py build execution failed.
ERROR: scipy-1.0.0-r0 do_compile: Function failed: do_compile (log file is
located at /log.do_compile.8708)
ERROR: Logfile of failure stored in: /1.0.0-r0/temp/log.do_compile.8708
Log data follows:
| DEBUG: Executing shell function do_compile
| ERROR: python setup.py build execution failed.
| /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'python_requires'
|   warnings.warn(msg)
| lapack_opt_info:
| openblas_lapack_info:
|   libraries openblas not found in ['/usr/lib']
|   NOT AVAILABLE
|
| lapack_mkl_info:
| mkl_info:
|   libraries mkl,vml,guide not found in ['/usr/lib']
|   NOT AVAILABLE
|
|   NOT AVAILABLE
|
| atlas_3_10_threads_info:
| Setting PTATLAS=ATLAS
|   libraries tatlas,tatlas not found in /usr/lib
|   libraries lapack_atlas not found in /usr/lib
| 
|   NOT AVAILABLE
|
| atlas_3_10_info:
|   libraries satlas,satlas not found in /usr/lib
|   libraries lapack_atlas not found in /usr/lib
| 
|   NOT AVAILABLE
|
| atlas_threads_info:
| Setting PTATLAS=ATLAS
|   libraries ptf77blas,ptcblas,atlas not found in /usr/lib
|   libraries lapack_atlas not found in /usr/lib
| 
|   NOT AVAILABLE
|
| atlas_info:
|   libraries f77blas,cblas,atlas not found in /usr/lib
|   libraries lapack_atlas not found in /usr/lib
| 
|   NOT AVAILABLE
|
|  /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1510:
UserWarning:
| Atlas (http://math-atlas.sourceforge.net/) libraries not found.
| Directories to search for the libraries can be specified in the
| numpy/distutils/site.cfg file (section [atlas]) or by setting
| the ATLAS environment variable.
|   warnings.warn(AtlasNotFoundError.__doc__)
| lapack_info:
|   libraries lapack not found in ['/usr/lib']
|   NOT AVAILABLE
|
| /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1521:
UserWarning:
| Lapack (http://www.netlib.org/lapack/) libraries not found.
| Directories to search for the libraries can be specified in the
| numpy/distutils/site.cfg file (section [lapack]) or by setting
| the LAPACK environment variable.
|   warnings.warn(LapackNotFoundError.__doc__)
| lapack_src_info:
|   NOT AVAILABLE
|
| /usr/lib/python2.7/site-packages/numpy/distutils/system_info.py:1524:
UserWarning:
| Lapack (http://www.netlib.org/lapack/) sources not found.
| Directories to search for the sources can be specified in the
| numpy/distutils/site.cfg file (section [lapack_src]) or by setting
| the LAPACK_SRC environment variable.
|   warnings.warn(LapackSrcNotFoundError.__doc__)
|   NOT AVAILABLE
|
| Running from scipy source directory.
| Traceback (most recent call last):
|   File "setup.py", line 418, in 
| setup_package()
|   File "setup.py", line 414, in setup_package
| setup(**metadata)
|   File "/usr/lib/python2.7/site-packages/numpy/distutils/core.py", line
135, in setup
| config = configuration()
|   File "setup.py", line 336, in configuration
| config.add_subpackage('scipy')
|   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
line 1003, in add_subpackage
| caller_level = 2)
|   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
line 972, in get_subpackage
| caller_level = caller_level + 1)
|   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
line 909, in _get_configuration_from_setup_py
| config = setup_module.configuration(*args)
|   File "scipy/setup.py", line 15, in configuration
| config.add_subpackage('linalg')
|   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
line 1003, in add_subpackage
| caller_level = 2)
|   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
line 972, in get_subpackage
| caller_level = caller_level + 1)
|   File "/usr/lib/python2.7/site-packages/numpy/distutils/misc_util.py",
line 909, in _get_configuration_from_setup_py
| config = setup_module.configuration(*args)
|   File "scipy/linalg/setup.py", line 19, in configuration
| raise NotFoundError('no lapack/blas resources found')
| numpy.distutils.system_info.NotFoundError: no lapack/blas resources found
| ERROR: Function failed: do_compile (log file is located at
/scipy/1.0.0-r0/temp/log.do_compile.8708)
ERROR: Task
(/sources/meta-openembedded/meta-python/recipes-devtools/python/scipy_1.0.0.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 8394 tasks of which 8382 didn't need to be
rerun and 1 failed.


On Fri, Mar 16, 2018 at 6:36 PM, Burton, Ross  wrote:

> To change the version, change the filename of the recipe.
>
> Also, please remember the CC the list.
>
> Ross
>
> On 16 March 2018 at 17:30, Peter Balazovic 
> wrote:
>
>> I did download from https://github.com/scipy/scipy/archive/v1.0.0.tar.gz
>> and cc to /downloads and same still issue ...
>> as 

[yocto] [sda] Attached SCSI removable disk.

[DSouza, NelsonX]

Hi,

I created a bootable USB image for core-image-sato and upon boot up it gets 
stuck at -


sda : sda1
sd 2:0:0:0:  [sda] Attached SCSI removable disk.

I am using is an Apollo Lake (UTX-3117).

PS: I had to run the diskpart utility prior to copying the yocto image over to 
reclaim space on this usb drive.

Thanks,
Nelson




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

[yocto] [PATCH][AUH] Add a commit_revert_policy configuration setting

[Alexander Kanavin]

This helps in particular when a package upgrade builds fine, but then
causes other packages to fail. Depending on how close to the root
of dependency tree the failing packages are, this can badly subvert
the unattended upgrade process. So for that case, the better approach
is to revert every upgrade commit, so that each upgrade is effectively
built against master, which makes it less likely to fail.

Signed-off-by: Alexander Kanavin 
---
 upgrade-helper.conf | 13 +
 upgradehelper.py|  6 +-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/upgrade-helper.conf b/upgrade-helper.conf
index b84b407..98ef58f 100644
--- a/upgrade-helper.conf
+++ b/upgrade-helper.conf
@@ -74,6 +74,19 @@
 # about what has changed in the resulting packages, compared to previous 
version
 #buildhistory=yes
 
+# When AUH has built an upgraded recipe it then creates a commit with the 
upgrade.
+# This setting specifies whether to also revert the commit. Possible values 
are:
+# 'failed_to_build' (default) - revert if the recipe failed to build. This is 
useful
+# to prevent further upgrades in the batch from failing, if they're dependent 
on the
+# recipe.
+# 'all' - always revert. This is useful when running automatic, unattended 
upgrades,
+#  as it will effectively test each upgrade against the baseline, and will 
avoid the 
+# situation where one successful upgrade thwarts others due to newly 
introduced 
+# incompatibilities.
+# 'never' - never revert. Use in interactive upgrade sessions, where any 
issues can be
+# manually fixed.
+#commit_revert_policy=failed_to_build
+
 # If enabled, build and boots a test image, and runs integration tests on it
 # If upgraded packages have ptest support those are run as well
 #testimage=no
diff --git a/upgradehelper.py b/upgradehelper.py
index d868cde..b5e696e 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -376,9 +376,13 @@ class Updater(object):
 else:
 I(" %s: Save patch in directory: %s." %
 (pkg_ctx['PN'], pkg_ctx['workdir']))
-if pkg_ctx['error'] is not None:
+revert_policy = settings.get('commit_revert_policy', 
'failed_to_build')
+if (pkg_ctx['error'] is not None and revert_policy == 
'failed_to_build'):
 I("Due to build errors, the commit will also be reverted to 
avoid cascading upgrade failures.")
 self.git.revert("HEAD")
+elif revert_policy == 'all':
+I("The commit will be reverted to follow the policy set in the 
configuration file.")
+self.git.revert("HEAD")
 except Error as e:
 msg = ''
 
-- 
2.16.1

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

Re: [yocto] scipy recipe

[Burton, Ross]

To change the version, change the filename of the recipe.

Also, please remember the CC the list.

Ross

On 16 March 2018 at 17:30, Peter Balazovic 
wrote:

> I did download from https://github.com/scipy/scipy/archive/v1.0.0.tar.gz
> and cc to /downloads and same still issue ...
> as mentioned  should be version is 1.0.0
> where to change it to point to correct version & file?
>
> On Fri, Mar 16, 2018 at 5:57 PM, Burton, Ross 
> wrote:
>
>> You're getting a "file not found" for the URL it is looking for.
>> According to https://pypi.python.org/pypi/scipy, the version is 1.0.0
>> not 1.0.
>>
>> Ross
>>
>> On 16 March 2018 at 16:50, Peter Balazovic 
>> wrote:
>>
>>> per using recipe https://github.com/scipy/scipy/issues/8226
>>>
>>>
>>> SUMMARY = "Scientific Library for Python"
>>> SECTION = "devel/python"
>>> HOMEPAGE = "https://pypi.python.org/pypi/scipy;
>>>
>>> LICENSE = "BSD-3-Clause"
>>> LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=d0db8f4148a3d5534cfb93be78f9287c"
>>>
>>> PYPI_PACKAGE="scipy"
>>>
>>> SRC_URI[md5sum] = "53fa34bd3733a9a4216842b6000f7316"
>>> SRC_URI[sha256sum] = 
>>> "87ea1f11a0e9ec08c264dc64551d501fa307289460705f6fccd84cbfc7926d10"
>>>
>>> inherit pypi setuptools distutils
>>>
>>> RDEPENDS_${PN} += "python-core python-numpy-native python-distutils"
>>> DEPENDS += "python-numpy"
>>>
>>>
>>> I am getting error to fetch scipy do_fetch error
>>>
>>>
>>> WARNING: scipy-1.0-r0 do_fetch: Failed to fetch URL
>>> https://files.pythonhosted.org/packages/source/s/scipy/scipy-1.0.tar.gz,
>>> attempting MIRRORS if available
>>> ERROR: scipy-1.0-r0 do_fetch: Fetcher failure: Fetch command export
>>> DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-idNNJsmT3C"; export
>>> SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export ftp_proxy=
>>> --progress=dot -v failed with exit code 8, output:
>>> --2018-03-16 17:43:34--  https://files.pythonhosted.org
>>> /packages/source/s/scipy/scipy-1.0.tar.gz
>>> Resolving files.pythonhosted.org (files.pythonhosted.org)...
>>> 151.101.17.63, 2a04:4e42:4::319
>>> Connecting to files.pythonhosted.org 
>>> (files.pythonhosted.org)|151.101.17.63|:443...
>>> connected.
>>> HTTP request sent, awaiting response... 404 Not Found
>>> 2018-03-16 17:43:35 ERROR 404: Not Found.
>>>
>>> Any help?
>>>
>>>
>>> On Thu, Mar 15, 2018 at 9:35 PM, Randy MacLeod <
>>> randy.macl...@windriver.com> wrote:
>>>
 On 2018-03-15 01:56 PM, Peter Balazovic wrote:

> Hello all,
>
> I wonder if there is scipy recipe available?
>

 Not yet:

 https://layers.openembedded.org/layerindex/branch/master/rec
 ipes/?q=scipy

 It appears to be blocked by:
https://github.com/scipy/scipy/issues/8226
 but apparently that's a bitbake issue, not a spip one.
 Care to take a look?


> Thanks.
>
>
>

 --
 # Randy MacLeod.  WR Linux
 # Wind River an Intel Company

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

Re: [yocto] scipy recipe

[Burton, Ross]

You're getting a "file not found" for the URL it is looking for.  According
to https://pypi.python.org/pypi/scipy, the version is 1.0.0 not 1.0.

Ross

On 16 March 2018 at 16:50, Peter Balazovic 
wrote:

> per using recipe https://github.com/scipy/scipy/issues/8226
>
>
> SUMMARY = "Scientific Library for Python"
> SECTION = "devel/python"
> HOMEPAGE = "https://pypi.python.org/pypi/scipy;
>
> LICENSE = "BSD-3-Clause"
> LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=d0db8f4148a3d5534cfb93be78f9287c"
>
> PYPI_PACKAGE="scipy"
>
> SRC_URI[md5sum] = "53fa34bd3733a9a4216842b6000f7316"
> SRC_URI[sha256sum] = 
> "87ea1f11a0e9ec08c264dc64551d501fa307289460705f6fccd84cbfc7926d10"
>
> inherit pypi setuptools distutils
>
> RDEPENDS_${PN} += "python-core python-numpy-native python-distutils"
> DEPENDS += "python-numpy"
>
>
> I am getting error to fetch scipy do_fetch error
>
>
> WARNING: scipy-1.0-r0 do_fetch: Failed to fetch URL
> https://files.pythonhosted.org/packages/source/s/scipy/scipy-1.0.tar.gz,
> attempting MIRRORS if available
> ERROR: scipy-1.0-r0 do_fetch: Fetcher failure: Fetch command export
> DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-idNNJsmT3C"; export
> SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export ftp_proxy=
> --progress=dot -v failed with exit code 8, output:
> --2018-03-16 17:43:34--  https://files.pythonhosted.
> org/packages/source/s/scipy/scipy-1.0.tar.gz
> Resolving files.pythonhosted.org (files.pythonhosted.org)...
> 151.101.17.63, 2a04:4e42:4::319
> Connecting to files.pythonhosted.org 
> (files.pythonhosted.org)|151.101.17.63|:443...
> connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2018-03-16 17:43:35 ERROR 404: Not Found.
>
> Any help?
>
>
> On Thu, Mar 15, 2018 at 9:35 PM, Randy MacLeod <
> randy.macl...@windriver.com> wrote:
>
>> On 2018-03-15 01:56 PM, Peter Balazovic wrote:
>>
>>> Hello all,
>>>
>>> I wonder if there is scipy recipe available?
>>>
>>
>> Not yet:
>>
>> https://layers.openembedded.org/layerindex/branch/master/recipes/?q=scipy
>>
>> It appears to be blocked by:
>>https://github.com/scipy/scipy/issues/8226
>> but apparently that's a bitbake issue, not a spip one.
>> Care to take a look?
>>
>>
>>> Thanks.
>>>
>>>
>>>
>>
>> --
>> # Randy MacLeod.  WR Linux
>> # Wind River an Intel Company
>>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Robert P. J. Day]

On Fri, 16 Mar 2018, Giordon Stark wrote:

> Right, so the problem for me is that there seems to be two ways to
> do this: MACHINEOVERRIDES .= ":machine3" (for 3a, 3b)
>
> or
>
> FILESEXTRAPATHS_append_machine3a = "${THISDIR}/files/machine3/"
> FILESEXTRAPATHS_append_machine3b = "${THISDIR}/files/machine3/"
>
> But it's not clear to me which is better or fits with the
> philosophy of yocto/bitbake.

  i used something like this once upon a time, can't remember where i
wrote it up, but i asked about it in some detail back here:

https://lists.yoctoproject.org/pipermail/yocto/2016-March/028923.html

perhaps someone can verify if i made any sense back then.

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

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Giordon Stark]

Right, so the problem for me is that there seems to be two ways to do this:

MACHINEOVERRIDES .= ":machine3" (for 3a, 3b)

or

FILESEXTRAPATHS_append_machine3a = "${THISDIR}/files/machine3/"
FILESEXTRAPATHS_append_machine3b = "${THISDIR}/files/machine3/"

But it's not clear to me which is better or fits with the philosophy of
yocto/bitbake.

Giordon

On Fri, Mar 16, 2018 at 11:48 AM Robert P. J. Day 
wrote:

> On Fri, 16 Mar 2018, Burton, Ross wrote:
>
> > On 15 March 2018 at 14:07, Giordon Stark  wrote:
> >   So for my device trees, I'm finding some files are duplicated. In
> particular some of my
> >   dtsi files are going to be the same amongst a few boards we're
> using, so I would like
> >   to have each machine name distinct so that
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >
> > files/${MACHINE}/${MACHINE}.dts
> >
> > is picked up, while still having
> >
> > files/common/*.dtsi picked up as well. As an example of my SRC_URI
> appends:
> >
> > SRC_URI_append_gfex-prototype1b = " \
> > file://skeleton.dtsi  \
> > file://pl.dtsi\
> > file://zynq-7000.dtsi \
> > file://system.dts \
> > "
> >
> > SRC_URI_append_gfex-prototype2  = " \
> > file://skeleton.dtsi   \
> > file://pl.dtsi \
> > file://zynq-7000.dtsi  \
> > file://system.dts  \
> > "
> >
> > I suspect I do something with OVERRIDES in the
> > conf/machine/${MACHINE}.conf file but not sure...
> >
> >
> > Can't you just put common files in files/file.dtsi and then the
> > machine-specific ones in files/[machine]/?
>
>   isn't this precisely what MACHINEOVERRIDES is for?
>
> rday

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

Re: [yocto] scipy recipe

[Peter Balazovic]

per using recipe https://github.com/scipy/scipy/issues/8226


SUMMARY = "Scientific Library for Python"
SECTION = "devel/python"
HOMEPAGE = "https://pypi.python.org/pypi/scipy;

LICENSE = "BSD-3-Clause"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=d0db8f4148a3d5534cfb93be78f9287c"

PYPI_PACKAGE="scipy"

SRC_URI[md5sum] = "53fa34bd3733a9a4216842b6000f7316"
SRC_URI[sha256sum] =
"87ea1f11a0e9ec08c264dc64551d501fa307289460705f6fccd84cbfc7926d10"

inherit pypi setuptools distutils

RDEPENDS_${PN} += "python-core python-numpy-native python-distutils"
DEPENDS += "python-numpy"


I am getting error to fetch scipy do_fetch error


WARNING: scipy-1.0-r0 do_fetch: Failed to fetch URL
https://files.pythonhosted.org/packages/source/s/scipy/scipy-1.0.tar.gz,
attempting MIRRORS if available
ERROR: scipy-1.0-r0 do_fetch: Fetcher failure: Fetch command export
DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-idNNJsmT3C"; export
SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export ftp_proxy=
--progress=dot -v failed with exit code 8, output:
--2018-03-16 17:43:34--
https://files.pythonhosted.org/packages/source/s/scipy/scipy-1.0.tar.gz
Resolving files.pythonhosted.org (files.pythonhosted.org)... 151.101.17.63,
2a04:4e42:4::319
Connecting to files.pythonhosted.org
(files.pythonhosted.org)|151.101.17.63|:443...
connected.
HTTP request sent, awaiting response... 404 Not Found
2018-03-16 17:43:35 ERROR 404: Not Found.

Any help?


On Thu, Mar 15, 2018 at 9:35 PM, Randy MacLeod 
wrote:

> On 2018-03-15 01:56 PM, Peter Balazovic wrote:
>
>> Hello all,
>>
>> I wonder if there is scipy recipe available?
>>
>
> Not yet:
>
> https://layers.openembedded.org/layerindex/branch/master/recipes/?q=scipy
>
> It appears to be blocked by:
>https://github.com/scipy/scipy/issues/8226
> but apparently that's a bitbake issue, not a spip one.
> Care to take a look?
>
>
>> Thanks.
>>
>>
>>
>
> --
> # Randy MacLeod.  WR Linux
> # Wind River an Intel Company
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Robert P. J. Day]

On Fri, 16 Mar 2018, Burton, Ross wrote:

> On 15 March 2018 at 14:07, Giordon Stark  wrote:
>   So for my device trees, I'm finding some files are duplicated. In 
> particular some of my
>   dtsi files are going to be the same amongst a few boards we're using, 
> so I would like
>   to have each machine name distinct so that 
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> files/${MACHINE}/${MACHINE}.dts
>
> is picked up, while still having
>
> files/common/*.dtsi picked up as well. As an example of my SRC_URI appends:
>
> SRC_URI_append_gfex-prototype1b = " \
>     file://skeleton.dtsi  \
>     file://pl.dtsi        \
>     file://zynq-7000.dtsi \
>     file://system.dts     \
> "
>
> SRC_URI_append_gfex-prototype2  = " \
>     file://skeleton.dtsi   \
>     file://pl.dtsi         \
>     file://zynq-7000.dtsi  \
>     file://system.dts      \
> "
>
> I suspect I do something with OVERRIDES in the
> conf/machine/${MACHINE}.conf file but not sure...
>
>
> Can't you just put common files in files/file.dtsi and then the
> machine-specific ones in files/[machine]/?

  isn't this precisely what MACHINEOVERRIDES is for?

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

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Burton, Ross]

Extend FILESEXTRAPATHS using machine-overrides to add common groupings?

Ross

On 16 March 2018 at 16:45, Giordon Stark  wrote:

> Hi,
>
> I would do that, but what I want to do is something like this:
>
> Machine1
> Machine2
> Machine3a
> Machine3b
> Machine4
>
> I want 3a/3b to have some shared dtsi files, but these should not be
> shared with machines 1, 2, 4. I'm not sure it's just a matter of placing it
> under files/ because I don't want those picked up by the non-3 machines.
>
> G
>
> On Fri, Mar 16, 2018 at 11:42 AM Burton, Ross 
> wrote:
>
>> On 15 March 2018 at 14:07, Giordon Stark  wrote:
>>
>>> So for my device trees, I'm finding some files are duplicated. In
>>> particular some of my dtsi files are going to be the same amongst a few
>>> boards we're using, so I would like to have each machine name distinct so
>>> that
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>>>
>>> files/${MACHINE}/${MACHINE}.dts
>>>
>>> is picked up, while still having
>>>
>>> files/common/*.dtsi picked up as well. As an example of my SRC_URI
>>> appends:
>>>
>>> SRC_URI_append_gfex-prototype1b = " \
>>> file://skeleton.dtsi  \
>>> file://pl.dtsi\
>>> file://zynq-7000.dtsi \
>>> file://system.dts \
>>> "
>>>
>>> SRC_URI_append_gfex-prototype2  = " \
>>> file://skeleton.dtsi   \
>>> file://pl.dtsi \
>>> file://zynq-7000.dtsi  \
>>> file://system.dts  \
>>> "
>>>
>>> I suspect I do something with OVERRIDES in the
>>> conf/machine/${MACHINE}.conf file but not sure...
>>>
>>
>> Can't you just put common files in files/file.dtsi and then the
>> machine-specific ones in files/[machine]/?
>>
>> Ross
>>
> --
> Giordon Stark
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Giordon Stark]

Hi,

I would do that, but what I want to do is something like this:

Machine1
Machine2
Machine3a
Machine3b
Machine4

I want 3a/3b to have some shared dtsi files, but these should not be shared
with machines 1, 2, 4. I'm not sure it's just a matter of placing it under
files/ because I don't want those picked up by the non-3 machines.

G

On Fri, Mar 16, 2018 at 11:42 AM Burton, Ross  wrote:

> On 15 March 2018 at 14:07, Giordon Stark  wrote:
>
>> So for my device trees, I'm finding some files are duplicated. In
>> particular some of my dtsi files are going to be the same amongst a few
>> boards we're using, so I would like to have each machine name distinct so
>> that
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>>
>> files/${MACHINE}/${MACHINE}.dts
>>
>> is picked up, while still having
>>
>> files/common/*.dtsi picked up as well. As an example of my SRC_URI
>> appends:
>>
>> SRC_URI_append_gfex-prototype1b = " \
>> file://skeleton.dtsi  \
>> file://pl.dtsi\
>> file://zynq-7000.dtsi \
>> file://system.dts \
>> "
>>
>> SRC_URI_append_gfex-prototype2  = " \
>> file://skeleton.dtsi   \
>> file://pl.dtsi \
>> file://zynq-7000.dtsi  \
>> file://system.dts  \
>> "
>>
>> I suspect I do something with OVERRIDES in the
>> conf/machine/${MACHINE}.conf file but not sure...
>>
>
> Can't you just put common files in files/file.dtsi and then the
> machine-specific ones in files/[machine]/?
>
> Ross
>
-- 
Giordon Stark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Burton, Ross]

On 15 March 2018 at 14:07, Giordon Stark  wrote:

> So for my device trees, I'm finding some files are duplicated. In
> particular some of my dtsi files are going to be the same amongst a few
> boards we're using, so I would like to have each machine name distinct so
> that
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> files/${MACHINE}/${MACHINE}.dts
>
> is picked up, while still having
>
> files/common/*.dtsi picked up as well. As an example of my SRC_URI appends:
>
> SRC_URI_append_gfex-prototype1b = " \
> file://skeleton.dtsi  \
> file://pl.dtsi\
> file://zynq-7000.dtsi \
> file://system.dts \
> "
>
> SRC_URI_append_gfex-prototype2  = " \
> file://skeleton.dtsi   \
> file://pl.dtsi \
> file://zynq-7000.dtsi  \
> file://system.dts  \
> "
>
> I suspect I do something with OVERRIDES in the
> conf/machine/${MACHINE}.conf file but not sure...
>

Can't you just put common files in files/file.dtsi and then the
machine-specific ones in files/[machine]/?

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

Re: [yocto] How to get mysqy/mariadb to start on powerup.

[Greg Wilson-Lindberg]

> From: Greg Wilson-Lindberg
> Sent: Thursday, March 15, 2018 02:16 PM
> To: Khem Raj 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
>

> > From: Khem Raj >
> > Sent: Thursday, March 15, 2018 1:54 PM
> > To: Greg Wilson-Lindberg
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] How to get mysqy/mariadb to start on powerup.
> >
> > > On Thu, Mar 15, 2018 at 1:38 PM, Greg Wilson-Lindberg
> > > wrote:
> > > I'm building an RPi3 system that is going to use mysql/mariadb. I've got
> > > everything installed, but mysqld is not starting. install_db.service does
> > > run on startup, but the mysqld.service file never gets triggered.
> > >
> > >
> > > Is there something that I'm missing to get it to run? I've search online,
> > > but can't find anything that pertains to yocto.
> > >
> >
> > poke on the system with systemctl/journalctl to see whats going on
>
> journalctl -u mysqld.service says no entries
> systemctl status mysqld.service shows:
>Loaded: loaded (/lib/systemd/system/mysqld.service; disabled; vendor 
> preset: enabled)
>Active: inactive (dead)
>
> I've rebooted the system a couple of times to see if install_db needed to be 
> run before mysql would run, no luck.
>
It's seems that maybe I need to add a bit about my understanding of the yocto 
system. I was assuming that if I included mysql in the build, that it would be 
started when the system powered up. If mysql is not normally started 
automatically that I can do what is necessary to start it, I just thought that 
I shouldn't need to do anything.

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

Re: [linux-yocto] [yocto-kernel-cache][PATCH] features/systemtap/systemtap.cfg: enable CONFIG_KERNEL_DEBUG

[Bruce Ashfield]

On 2018-03-16 2:36 AM, Victor Kamensky wrote:



On Wed, 14 Mar 2018, Bruce Ashfield wrote:


On 2018-03-14 11:54 AM, Victor Kamensky wrote:



On Wed, 14 Mar 2018, Bruce Ashfield wrote:


On 2018-03-14 10:41 AM, Victor Kamensky wrote:

Hi Bruce,

On Wed, 14 Mar 2018, Bruce Ashfield wrote:

As it turns out, Ross is reporting a big performance degradation 
in the kernel

in footprint, packaging and build time.

It completely slipped my mind when looking at this commit, that we 
went through

a split two years ago for that very same issue.

For now, I'm going to revert this,


Please note that after revert in your regular build kernels will not
be debuggable, because it is missing symbols. For example for 
investigation like [1] where kernel hangs where one can pick at

hangged kernel quickly after 'runnqemu qemuparam="-S -s"'. It is
not possible without symbols.


That's fully understood. But we cannot have that config on for
the standard kernel build. That's what the developer ktype is for.




and then work systemtap properly into the
developer kernel type. The issue is that the standard kernel 
includes systemtap
by default (it probably shouldn't), and hence is picking up the 
DEBUG_KERNEL

option .. and that's causing the issues.


Even if you revert commit please do not remove systemtap fragment
from regular kernel. I said that without CONFIG_KERNEL_DEBUG
kernel tracing does not make sense. But besides kernel systemtap
can do user-land process tracing, this one works OK even if symbols
are not in kernel.

Instead of removing systemtap.cfg from regular kernel, it would be
better to add separate debuginfo.cfg that would enable debug
symbols kernle and have some quick way through which one can add
symbols through simple local.conf setting. So if run into situation
like [1], and need to look at kernel with gdb or run systemtap
against it, one can just add line to local.conf and rebuild kernel.


There's already a fragment for that purpose and it is what the
developer kernel type uses. Anyone can include that fragment via
a bbappend.

The developer kernel type includes the standard kernel, so it is
a superset .. so yes, I can leave systemtap in place and the developer
kernel type just finishes the enablement of it.


I will look at kernel ktype mechanism. But if in developper
fragment there are some other options, it may not be suitable
for use cases that I have in mind. Suppose one runs into the


We can always make the fragments more granular, what is there is
just the first pass.


problem with kenel and would like to debug it with gdb or write
systemtap script to investigate it. There should be a
way just to add symbols to it and leave all other configs intact,
because who knows maybe those config will change kernel behavior
and issue won't be reprodicible anymore. So I think there should
be a way to enable DEBUG_INFO symbols only quickly for any given
config. I'll try to look at how to do it, and will post some
RFC patches for it.


Sounds good. Let me know if you need any help on my end.


Just to close on this:

I looked closely and experimented with it. It seems that
everything I need is already in place. If I add

KERNEL_EXTRA_FEATURES_append = " features/debug/debug-kernel.scc"

to my conf/local.conf or conf/site.conf it will do the trick:
kernel will be built with symbols. debug-kernel.cfg contains
DEBUG_PREEMPT besided DEBUG_INFO, but it looks like it does not
make sense to move just DEBUG_INFO out because DEBUG_PREEMPT
default is 'y' and it will be enabled as soon as KERNEL_DEBUG
enabled. If debug-kernel.cfg will ever pick up more content,
maybe factoring out just DEBUG_INFO would make some sense.


Excellent, and agreed. I'll put a comment in that fragment that
warns about adding more options .. that way I'm not relying on
my memory to not bloat the fragment :D

Bruce



Thanks,
Victor


Bruce



Thanks,
Victor


Bruce



[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148587.html 
Thanks,

Victor

For now, you can build the developer kernel type, or add the 
developer kernel
configuration fragment via a bbappend, and you'll have a 
functional systemtap.


I can move systemtap out of the standard kernel and only into the 
developer

kernel, since as you say, it isn't functional without this option.
But, that ktype
hasn't gotten a lot of mileage (despite being around for two years),
so I'll need
to run some tests before I can truly move the fragment over and 
confirm that

it works.

So again, for now, I'll revert this, but will work on getting the
ktypes fixed up
as well.

Cheers,

Bruce


commit a7b57bb54cace686911faae9a8eace3b9cbf8145
Author: California Sullivan 
Date:   Wed Feb 17 16:47:10 2016 -0800

   ktypes: add developer ktype

   The developer ktype enables EMBEDDED, EXPERT, and DEBUG_KERNEL,
   opening up more kernel options and setting some defaults.

   Signed-off-by: California Sullivan 

Re: [yocto] OpenCV with python3

[Peter Balazovic]

By allowing "python3-opencv" I end up with errors 

ERROR: fsl-image-qt5-1.0-r0 do_rootfs: python3-opencv not found in the
feeds .
ERROR: fsl-image-qt5-1.0-r0 do_rootfs: This is often caused by an empty
package declared in a recipe's PACKAGES variable. (Empty packages are not
constructed unless ALLOW_EMPTY_ = '1' is used.)
ERROR: fsl-image-qt5-1.0-r0 do_rootfs: Function failed: do_rootfs

where to look at on problem?


On Fri, Mar 16, 2018 at 8:09 AM, Peter Balazovic 
wrote:

> That I was thinking to have “python3-opencv” but it's failing to build
>
> I found opencv_3.1.bbappend with my sources where I see
>
> PACKAGECONFIG_remove_imx = "eigen python3"
>
> I guess that might causing a problem to build opencv for python3... I'll
> remove and check again to build.
>
> BTW what's the benefit of using CORE_IMAGE_EXTRA_INSTALL over
> IMAGE_INSTALL_append ?
>
>
> On Fri, Mar 16, 2018 at 6:29 AM, Tim Orling  wrote:
>
>> Ditto for Robert’s comment. Please look at the bitbake manual and
>> understand what the syntax means [1].
>>
>> Also,  “python-foo” means the python2 version. The default PACKAGECONFIG
>> [2] for opencv builds for python3. You need “python3-opencv”.
>>
>> Finally, I would encourage you to use CORE_IMAGE_EXTRA_INSTALL [3] rather
>> than IMAGE_INSTALL in the local.conf context.
>>
>> [1] https://www.yoctoproject.org/docs/current/bitbake-user-m
>> anual/bitbake-user-manual.html#appending-and-prepending
>> [2] http://cgit.openembedded.org/meta-openembedded/tree/meta
>> -oe/recipes-support/opencv/opencv_3.3.bb?h=master#n90
>> [3] https://www.yoctoproject.org/docs/current/ref-manual/ref
>> -manual.html#var-CORE_IMAGE_EXTRA_INSTALL
>>
>> On Thu, Mar 15, 2018 at 5:57 AM Robert P. J. Day 
>> wrote:
>>
>>> On Thu, 15 Mar 2018, Peter Balazovic wrote:
>>>
>>> > Hello all,
>>> > I have python module of OpenCV for python 2.7 on my Yocto image adding
>>> via local.conf
>>> >
>>> > IMAGE_INSTALL_append += “ python-opencv”
>>>
>>>   i know i've harped on this before, but can people please stop
>>> combining the constructs "_append" and "+=" in the same expression?
>>>
>>> rday--
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] clarify instructions for package feed installation

[Peter A. Bigot]

On 03/16/2018 05:27 AM, Alexander Kanavin wrote:

On 03/15/2018 10:10 PM, Peter A. Bigot wrote:

Following the instructions in the 2.4.2 mega-manual section 4.21.4 I set
in local.conf:

 PACKAGE_FEED_URIS = "http://192.168.65.22/oe/rpi3-sumo;
 PACKAGE_FEED_BASE_PATHS = "rpm"
 PACKAGE_FEED_ARCHS = "noarch cortexa7hf_neon_vfpv4 raspberrypi3"

and run this command:

 bitbake package-index

This produces a repodata directory in the deploy/rpm directory, sibling
to the arch directories.

drwxr-xr-x 2 pab pab 516096 Mar 15 12:26 cortexa7hf_neon_vfpv4
drwxr-xr-x 2 pab pab  24576 Mar 15 12:55 noarch
drwxr-xr-x 2 pab pab 262144 Mar 15 12:26 raspberrypi3
drwxr-xr-x 2 pab pab   4096 Mar 15 15:02 repodata

However, the repo file generated by the PACKAGE_FEED variables causes
dnf on the target to fetch repodata from inside each arch directory:

192.168.65.117 - - [15/Mar/2018:14:03:18 -0500] "GET 
/oe/rpi3-sumo/rpm/noarch/repodata/repomd.xml HTTP/1.1" 404 481 "-" 
"dnf/2.7.5"
192.168.65.117 - - [15/Mar/2018:14:05:51 -0500] "GET 
/oe/rpi3-sumo/rpm/raspberrypi3/repodata/repomd.xml HTTP/1.1" 404 487 
"-" "dnf/2.7.5"
192.168.65.117 - - [15/Mar/2018:14:05:51 -0500] "GET 
/oe/rpi3-sumo/rpm/cortexa7hf_neon_vfpv4/repodata/repomd.xml HTTP/1.1" 
404 496 "-" "dnf/2.7.5"


This doesn't work.  I end up having to change the repo file to eliminate
the architectures.

Is this a problem specific to RPM, or am I doing something wrong?


I think the documentation is misleading here. 'bitbake package-index' 
generates a single index for all of the architectures in the 
deploy/rpm directory, so if you need individual feeds for specific 
architectures, you need to generate them yourself with a custom 
recipe. Or if you're okay with having a single index, just drop the 
PACKAGE_FEED_ARCHS setting.


CC Scott, so we can add a note for RPM feeds in the docs here.


Alex


Thanks; that makes sense.  A documentation note that PACKAGE_FEED_ARCHS 
should only be used if indexes are generated a different way would be 
worthwhile.  AFAICT the only time identifying specific architectures is 
useful is in filtering irrelevant candidates when multiple architectures 
are present. It's not immediately obvious how to put multiple 
incompatible archs into the same hierarchy anyway unless something 
automatically reconciles the companion noarch packages that get produced 
in builds for different MACHINEs.


Peter

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

Re: [yocto] package manager contamination in state?

[Alexander Kanavin]

On 03/15/2018 10:12 PM, Peter A. Bigot wrote:

While attempting to diagnose a package index problem visible on current
poky head I changed local.conf from:

PACKAGE_CLASSES ?= "package_rpm"

to

PACKAGE_CLASSES ?= "package_deb"


Note that we don't test deb packaging all that well. I'm not even sure 
images are regularly built with it on the autobuilder. It does seem like 
apt has some kind of dependency problem where dnf sees none.



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

Re: [yocto] clarify instructions for package feed installation

[Alexander Kanavin]

On 03/15/2018 10:10 PM, Peter A. Bigot wrote:

Following the instructions in the 2.4.2 mega-manual section 4.21.4 I set
in local.conf:

     PACKAGE_FEED_URIS = "http://192.168.65.22/oe/rpi3-sumo;
     PACKAGE_FEED_BASE_PATHS = "rpm"
     PACKAGE_FEED_ARCHS = "noarch cortexa7hf_neon_vfpv4 raspberrypi3"

and run this command:

     bitbake package-index

This produces a repodata directory in the deploy/rpm directory, sibling
to the arch directories.

drwxr-xr-x 2 pab pab 516096 Mar 15 12:26 cortexa7hf_neon_vfpv4
drwxr-xr-x 2 pab pab  24576 Mar 15 12:55 noarch
drwxr-xr-x 2 pab pab 262144 Mar 15 12:26 raspberrypi3
drwxr-xr-x 2 pab pab   4096 Mar 15 15:02 repodata

However, the repo file generated by the PACKAGE_FEED variables causes
dnf on the target to fetch repodata from inside each arch directory:

192.168.65.117 - - [15/Mar/2018:14:03:18 -0500] "GET 
/oe/rpi3-sumo/rpm/noarch/repodata/repomd.xml HTTP/1.1" 404 481 "-" 
"dnf/2.7.5"
192.168.65.117 - - [15/Mar/2018:14:05:51 -0500] "GET 
/oe/rpi3-sumo/rpm/raspberrypi3/repodata/repomd.xml HTTP/1.1" 404 487 "-" 
"dnf/2.7.5"
192.168.65.117 - - [15/Mar/2018:14:05:51 -0500] "GET 
/oe/rpi3-sumo/rpm/cortexa7hf_neon_vfpv4/repodata/repomd.xml HTTP/1.1" 
404 496 "-" "dnf/2.7.5"


This doesn't work.  I end up having to change the repo file to eliminate
the architectures.

Is this a problem specific to RPM, or am I doing something wrong?


I think the documentation is misleading here. 'bitbake package-index' 
generates a single index for all of the architectures in the deploy/rpm 
directory, so if you need individual feeds for specific architectures, 
you need to generate them yourself with a custom recipe. Or if you're 
okay with having a single index, just drop the PACKAGE_FEED_ARCHS setting.


CC Scott, so we can add a note for RPM feeds in the docs here.


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

Re: [yocto] OpenCV with python3

[Peter Balazovic]

That I was thinking to have “python3-opencv” but it's failing to build

I found opencv_3.1.bbappend with my sources where I see

PACKAGECONFIG_remove_imx = "eigen python3"

I guess that might causing a problem to build opencv for python3... I'll
remove and check again to build.

BTW what's the benefit of using CORE_IMAGE_EXTRA_INSTALL over
IMAGE_INSTALL_append ?


On Fri, Mar 16, 2018 at 6:29 AM, Tim Orling  wrote:

> Ditto for Robert’s comment. Please look at the bitbake manual and
> understand what the syntax means [1].
>
> Also,  “python-foo” means the python2 version. The default PACKAGECONFIG
> [2] for opencv builds for python3. You need “python3-opencv”.
>
> Finally, I would encourage you to use CORE_IMAGE_EXTRA_INSTALL [3] rather
> than IMAGE_INSTALL in the local.conf context.
>
> [1] https://www.yoctoproject.org/docs/current/bitbake-user-
> manual/bitbake-user-manual.html#appending-and-prepending
> [2] http://cgit.openembedded.org/meta-openembedded/tree/
> meta-oe/recipes-support/opencv/opencv_3.3.bb?h=master#n90
> [3] https://www.yoctoproject.org/docs/current/ref-manual/
> ref-manual.html#var-CORE_IMAGE_EXTRA_INSTALL
>
> On Thu, Mar 15, 2018 at 5:57 AM Robert P. J. Day 
> wrote:
>
>> On Thu, 15 Mar 2018, Peter Balazovic wrote:
>>
>> > Hello all,
>> > I have python module of OpenCV for python 2.7 on my Yocto image adding
>> via local.conf
>> >
>> > IMAGE_INSTALL_append += “ python-opencv”
>>
>>   i know i've harped on this before, but can people please stop
>> combining the constructs "_append" and "+=" in the same expression?
>>
>> rday--
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [yocto-kernel-cache][PATCH] features/systemtap/systemtap.cfg: enable CONFIG_KERNEL_DEBUG

[Victor Kamensky]

On Wed, 14 Mar 2018, Bruce Ashfield wrote:


On 2018-03-14 11:54 AM, Victor Kamensky wrote:



On Wed, 14 Mar 2018, Bruce Ashfield wrote:


On 2018-03-14 10:41 AM, Victor Kamensky wrote:

Hi Bruce,

On Wed, 14 Mar 2018, Bruce Ashfield wrote:

As it turns out, Ross is reporting a big performance degradation in the 
kernel

in footprint, packaging and build time.

It completely slipped my mind when looking at this commit, that we went 
through

a split two years ago for that very same issue.

For now, I'm going to revert this,


Please note that after revert in your regular build kernels will not
be debuggable, because it is missing symbols. For example for 
investigation like [1] where kernel hangs where one can pick at

hangged kernel quickly after 'runnqemu qemuparam="-S -s"'. It is
not possible without symbols.


That's fully understood. But we cannot have that config on for
the standard kernel build. That's what the developer ktype is for.




and then work systemtap properly into the
developer kernel type. The issue is that the standard kernel includes 
systemtap
by default (it probably shouldn't), and hence is picking up the 
DEBUG_KERNEL

option .. and that's causing the issues.


Even if you revert commit please do not remove systemtap fragment
from regular kernel. I said that without CONFIG_KERNEL_DEBUG
kernel tracing does not make sense. But besides kernel systemtap
can do user-land process tracing, this one works OK even if symbols
are not in kernel.

Instead of removing systemtap.cfg from regular kernel, it would be
better to add separate debuginfo.cfg that would enable debug
symbols kernle and have some quick way through which one can add
symbols through simple local.conf setting. So if run into situation
like [1], and need to look at kernel with gdb or run systemtap
against it, one can just add line to local.conf and rebuild kernel.


There's already a fragment for that purpose and it is what the
developer kernel type uses. Anyone can include that fragment via
a bbappend.

The developer kernel type includes the standard kernel, so it is
a superset .. so yes, I can leave systemtap in place and the developer
kernel type just finishes the enablement of it.


I will look at kernel ktype mechanism. But if in developper
fragment there are some other options, it may not be suitable
for use cases that I have in mind. Suppose one runs into the


We can always make the fragments more granular, what is there is
just the first pass.


problem with kenel and would like to debug it with gdb or write
systemtap script to investigate it. There should be a
way just to add symbols to it and leave all other configs intact,
because who knows maybe those config will change kernel behavior
and issue won't be reprodicible anymore. So I think there should
be a way to enable DEBUG_INFO symbols only quickly for any given
config. I'll try to look at how to do it, and will post some
RFC patches for it.


Sounds good. Let me know if you need any help on my end.


Just to close on this:

I looked closely and experimented with it. It seems that
everything I need is already in place. If I add

KERNEL_EXTRA_FEATURES_append = " features/debug/debug-kernel.scc"

to my conf/local.conf or conf/site.conf it will do the trick:
kernel will be built with symbols. debug-kernel.cfg contains
DEBUG_PREEMPT besided DEBUG_INFO, but it looks like it does not
make sense to move just DEBUG_INFO out because DEBUG_PREEMPT
default is 'y' and it will be enabled as soon as KERNEL_DEBUG
enabled. If debug-kernel.cfg will ever pick up more content,
maybe factoring out just DEBUG_INFO would make some sense.

Thanks,
Victor


Bruce



Thanks,
Victor


Bruce



[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148587.html 
Thanks,

Victor

For now, you can build the developer kernel type, or add the developer 
kernel
configuration fragment via a bbappend, and you'll have a functional 
systemtap.


I can move systemtap out of the standard kernel and only into the 
developer

kernel, since as you say, it isn't functional without this option.
But, that ktype
hasn't gotten a lot of mileage (despite being around for two years),
so I'll need
to run some tests before I can truly move the fragment over and confirm 
that

it works.

So again, for now, I'll revert this, but will work on getting the
ktypes fixed up
as well.

Cheers,

Bruce


commit a7b57bb54cace686911faae9a8eace3b9cbf8145
Author: California Sullivan 
Date:   Wed Feb 17 16:47:10 2016 -0800

   ktypes: add developer ktype

   The developer ktype enables EMBEDDED, EXPERT, and DEBUG_KERNEL,
   opening up more kernel options and setting some defaults.

   Signed-off-by: California Sullivan 
   Signed-off-by: Bruce Ashfield 

:00 100644 ... ee04ec720188... A
ktypes/developer/developer.cfg
:00 100644 ... cf2c0e6519d5... A
ktypes/developer/developer.scc