Re: [yocto] Error Report Tool Purge

[Martin Jansa]

OK, so it's only visited links, not linked from ML or wiki or whatever,
right?

How huge the database is? I've checked our internal instance and on
relatively slow VM we have:
47 472 724 Post_buildstatstask
2 715 091 Post_build
559 655 Post_buildfailure

we use postgresql, the db currently has 20GB, which is quite big for VM
with 10GB RAM and 12 E5-2699 cores so it's slow as well, but not terribly
slow, individual builds or build-failures are really fast, there are some
bad queries in django which are terrible, but we're not using those usually.

Cheers,


On Thu, Jul 19, 2018 at 9:01 PM Brindle, Amanda R <
amanda.r.brin...@intel.com> wrote:

> Every time a specific report is visited (with the end of the URL being
> /Errors/Details/), we are tracking if the referrer is another website,
> the reporting tool itself, or unknown. If the referrer is another website
> or unknown, then we won’t delete it.
>
>
>
> The purge script does not look at links to whole builds, so as it is right
> now, those would get deleted. If it’s common to link to whole builds,
> though, I can add something to the script to save reports from a visited or
> linked build.
>
>
>
> -Amanda Brindle
>
>
>
> *From:* Martin Jansa [mailto:martin.ja...@gmail.com]
> *Sent:* Thursday, July 19, 2018 11:38 AM
> *To:* Brindle, Amanda R 
> *Cc:* Yocto Project 
> *Subject:* Re: [yocto] Error Report Tool Purge
>
>
>
> I'm just curious, how are you tracking which reports were viewed or linked
> to (and linked from where)? I often use a link to
> http://errors.yoctoproject.org in the mailing list or the recipes/commit
> message instead of copy pasting whole build error, because it already
> shortens the build paths and shows useful additional information about the
> error.
>
>
>
> The links to whole builds on http://errors.yoctoproject.org were also
> often linked from "bitbake world status" e-mails and wiki like:
>
> https://www.openembedded.org/wiki/Bitbake_World_Status_Rocko
>
> and on many of them nobody clicked yet - should I expect that these will
> mostly get broken?
>
>
>
> Regards
>
>
>
>
>
>
>
> On Thu, Jul 19, 2018 at 8:30 PM Brindle, Amanda R <
> amanda.r.brin...@intel.com> wrote:
>
> Hello,
>
>
>
> The Error Reporting Tool’s database (
> http://errors.yoctoproject.org/Errors/Latest/Autobuilder/)  has grown to
> a huge size, and this is affecting the performance of the application. We
> are planning to run a purge to get rid of reports that we don’t need. We
> will keep reports from the last thirty days, as well as reports that have
> been viewed or linked to. If you have a specific report that you don’t want
> purged, please let me know by the end of the month.
>
>
>
> Amanda Brindle, Software Engineer
>
> 503-264-3970
>
> amanda.r.brin...@intel.com
>
>
>
> --
> ___
> 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] net-snmp 5.8 recipe

[Burton, Ross]

Read the configure log and it will tell you what went wrong, which may
or may not be easy to fix.

Ross

On 19 July 2018 at 22:01, Simon Chamlian  wrote:
> Hi,
>
> Is there any recipe for the new snmp release 5.8 ?
>
> I took the net-snmp_5.7.3.bb file and renamed it net-snmp_5.8.bb
> removed the patches and re-entered the checksum but it still giving me
> errors.
>
> ERROR: net-snmp-5.8-r0 do_configure: This autoconf log indicates errors, it
> looked at host include and/or library paths while determining system
> capabilities.
> Rerun configure task after fixing this.
> ERROR: net-snmp-5.8-r0 do_configure: Function failed: do_qa_configure
> ERROR: Logfile of failure stored in:
> /opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/net-snmp/5.8-r0/temp/log.do_configure.394
> ERROR: Task
> (/opt/PHYTEC_BSPs/yocto_imx7/sources/meta-openembedded/meta-networking/recipes-protocols/net-snmp/net-snmp_5.8.bb:do_configure)
> failed with exit code '1'
>
> See attached for the recipe.
>
> Thanks,
> S
>
>
>
>
> --
> ___
> 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] Error Report Tool Purge

[Khem Raj]

On Thu, Jul 19, 2018 at 11:30 AM Brindle, Amanda R
 wrote:
>
> Hello,
>
>
>
> The Error Reporting Tool’s database 
> (http://errors.yoctoproject.org/Errors/Latest/Autobuilder/)  has grown to a 
> huge size, and this is affecting the performance of the application. We are 
> planning to run a purge to get rid of reports that we don’t need. We will 
> keep reports from the last thirty days, as well as reports that have been 
> viewed or linked to. If you have a specific report that you don’t want 
> purged, please let me know by the end of the month.
>
>

this is a good step, I have almost stopped using this tool due to
slowness, however for pruning, I think it would
be good to see if we can throw away duplicate logs and just keep the
counts, May be its already done.
secondly, release branches dont get built that often as compared to
dev branches so we need to keep that in mind
may be per branch policy would be good to have.

>
> Amanda Brindle, Software Engineer
>
> 503-264-3970
>
> amanda.r.brin...@intel.com
>
>
>
> --
> ___
> 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] net-snmp 5.8 recipe

[Simon Chamlian]

Hi,

Is there any recipe for the new snmp release 5.8 ?

I took the net-snmp_5.7.3.bb file and renamed it net-snmp_5.8.bb
removed the patches and re-entered the checksum but it still giving me
errors.

ERROR: net-snmp-5.8-r0 do_configure: This autoconf log indicates errors, it
looked at host include and/or library paths while determining system
capabilities.
Rerun configure task after fixing this.
ERROR: net-snmp-5.8-r0 do_configure: Function failed: do_qa_configure
ERROR: Logfile of failure stored in:
/opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/net-snmp/5.8-r0/temp/log.do_configure.394
ERROR: Task
(/opt/PHYTEC_BSPs/yocto_imx7/sources/meta-openembedded/meta-networking/recipes-protocols/net-snmp/net-snmp_5.8.bb:do_configure)
failed with exit code '1'

See attached for the recipe.

Thanks,
S


net-snmp_5.8.bb
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.2.4 RC1

[richard . purdie]

On Thu, 2018-07-19 at 09:55 +, Yeoh, Ee Peng wrote:
> This is the full report for 2.2.4.rc1:  
> https://wiki.yoctoproject.org/wiki/WW28_-_2018-07-13_-_Full_Test_Cycl
> e_2.2.4_rc1
>  
> === Summary 
>  
> All planned tests were executed.  There were zero high milestone
> defect.  Team had found 3 new defects [1] [2] [3] where runtime
> test_parselogs testcase failed with error message inside dmesg
> log.  While executing the runtime smart package manager tests on
> target platform to install psplash, team discovered that the target
> platform screen was splash with Yocto logo and the Yocto logo remain
> after the tests completed, need further investigation to verify if
> this was caused by post installation script from psplash.  For
> performance test, regression on 2.2.3.rc2 faced with error where
> SRCREV defined for distcc was no longer available.  For pTest, both
> glib-2.0 and util-linux passrate decreased as compared to 2.2.3.rc2
> as some new tests available in 2.2.4.rc1 were failing.   
>  
> === QA-Hints
>  
> Found 3 non critical defects.  
>  
> === Bugs 
>  
> New Bugs
> [1] Bug 12854 - [2.2.4.rc1][BSP Auto] [genericx86-64 on MMAX64bit]
> [test_parselogs] blk_update_request: I/O error, dev loop0
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12854
> 
> [2] Bug 12853 - [2.2.4.rc1][BSP Auto] [genericx86-64 on
> NUC6][test_parselogs] drm:intel_dp_link_training_clock_recovery]
> *ERROR* too many voltage retries, give up
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12853
> 
> [3] Bug 12852 - [2.2.4.rc1][BSP Auto] [genericx86-64-WIC on
> NUC6][test_parselogs] snd_hda_intel :00:1f.3: failed to add i915
> component master  
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12852

Thanks. One of these was resolved by the triage team as WONTFIX since
whilst there is a fix in master, backporting it has potential side
effects and in their view would be too risky for a stable release.

The other two issues were identified as being due to changes in QA team
hardware used for the testing and therefore are not regressions, just
error messages that appear on the newer testing hardware.

As such, I believe we should release 2.2.4.

Cheers,

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

Re: [yocto] Error Report Tool Purge

[Brindle, Amanda R]

Every time a specific report is visited (with the end of the URL being 
/Errors/Details/), we are tracking if the referrer is another website, the 
reporting tool itself, or unknown. If the referrer is another website or 
unknown, then we won’t delete it.

The purge script does not look at links to whole builds, so as it is right now, 
those would get deleted. If it’s common to link to whole builds, though, I can 
add something to the script to save reports from a visited or linked build.

-Amanda Brindle

From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: Thursday, July 19, 2018 11:38 AM
To: Brindle, Amanda R 
Cc: Yocto Project 
Subject: Re: [yocto] Error Report Tool Purge

I'm just curious, how are you tracking which reports were viewed or linked to 
(and linked from where)? I often use a link to http://errors.yoctoproject.org 
in the mailing list or the recipes/commit message instead of copy pasting whole 
build error, because it already shortens the build paths and shows useful 
additional information about the error.

The links to whole builds on http://errors.yoctoproject.org were also often 
linked from "bitbake world status" e-mails and wiki like:
https://www.openembedded.org/wiki/Bitbake_World_Status_Rocko
and on many of them nobody clicked yet - should I expect that these will mostly 
get broken?

Regards



On Thu, Jul 19, 2018 at 8:30 PM Brindle, Amanda R 
mailto:amanda.r.brin...@intel.com>> wrote:
Hello,

The Error Reporting Tool’s database 
(http://errors.yoctoproject.org/Errors/Latest/Autobuilder/)  has grown to a 
huge size, and this is affecting the performance of the application. We are 
planning to run a purge to get rid of reports that we don’t need. We will keep 
reports from the last thirty days, as well as reports that have been viewed or 
linked to. If you have a specific report that you don’t want purged, please let 
me know by the end of the month.

Amanda Brindle, Software Engineer
503-264-3970
amanda.r.brin...@intel.com

--
___
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] Error Report Tool Purge

[Martin Jansa]

I'm just curious, how are you tracking which reports were viewed or linked
to (and linked from where)? I often use a link to
http://errors.yoctoproject.org in the mailing list or the recipes/commit
message instead of copy pasting whole build error, because it already
shortens the build paths and shows useful additional information about the
error.

The links to whole builds on http://errors.yoctoproject.org were also often
linked from "bitbake world status" e-mails and wiki like:
https://www.openembedded.org/wiki/Bitbake_World_Status_Rocko
and on many of them nobody clicked yet - should I expect that these will
mostly get broken?

Regards



On Thu, Jul 19, 2018 at 8:30 PM Brindle, Amanda R <
amanda.r.brin...@intel.com> wrote:

> Hello,
>
>
>
> The Error Reporting Tool’s database (
> http://errors.yoctoproject.org/Errors/Latest/Autobuilder/)  has grown to
> a huge size, and this is affecting the performance of the application. We
> are planning to run a purge to get rid of reports that we don’t need. We
> will keep reports from the last thirty days, as well as reports that have
> been viewed or linked to. If you have a specific report that you don’t want
> purged, please let me know by the end of the month.
>
>
>
> Amanda Brindle, Software Engineer
>
> 503-264-3970
>
> amanda.r.brin...@intel.com
>
>
> --
> ___
> 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] Error Report Tool Purge

[Brindle, Amanda R]

Hello,

The Error Reporting Tool's database 
(http://errors.yoctoproject.org/Errors/Latest/Autobuilder/)  has grown to a 
huge size, and this is affecting the performance of the application. We are 
planning to run a purge to get rid of reports that we don't need. We will keep 
reports from the last thirty days, as well as reports that have been viewed or 
linked to. If you have a specific report that you don't want purged, please let 
me know by the end of the month.

Amanda Brindle, Software Engineer
503-264-3970
amanda.r.brin...@intel.com

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

[yocto] Minutes: Yocto Project Weekly Triage Meeting

[Jolley, Stephen K]

Attendees: Kosta, Randy, Stephen, Anuj, Amanda, Richard, Ross, Joshua, 
Alejandro, Paul,

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

AR: Anuj – Review 
12789.
AR: Paul – Check with Aaron about 
12698

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:  (208) 244-4460
• Email:stephen.k.jol...@intel.com


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

Re: [yocto] Setting recipe version inside an image recipe

[Mauro Ziliani]

Thank you.

Your suggestion is very useful.

The best choice at the end is to have one  recipe every stable version 
of myapp.


So I can freeze the true production recipe for that version.

Maybe in the future the recipe myapp could be evolve with some 
enhancement which could not be compatible with older version.


Good idea.

Best regards,

MZ

Il 19/07/2018 16:02, Paul Eggleton ha scritto:

Hi Mauro

On Thursday, 19 July 2018 2:36:18 PM CEST Mauro Ziliani wrote:

I'm working with Krogoth.

I'd like to do this.

- I have my application added to yocto tree by its own recipe myapp_git.bb

This recipe get the source code from a local git repository setting
SRCREV for the last stable application source code.

SRCREV is fixed in myapp_git.bb


- I have the recipe for the final production image for the embedded
system  myos.bb, which declare

IMAGE_INSTALL_append = " myapp "

The myos.bb compiles myapp with the version declare in myapp_git.bb recipe


I'd like to do that

- prepare a base recipe myos-base.inc  where I define all I need the
produce the final image with

IMAGE_INSTALL_append = " myapp "

- prepare myos.bb recipe where I can fix the version of myapp.bb to a
prpduction version

- prepare myos-test.bb recipre where I can fix the HEAD branch of git
from I can download the  latest source code for test.


I try this

- inside myapp_git.bb I put SRCREV="${MYAPP_SRCREV}"

- inside myos.bb I set MYAPP_SRCREV="prodution-version-X" to download
the tag/branch production-version-X

- inside myos-test.bb I set MYAPP_SRCREV="${AUTOREV}" to download the
latest git commit

You cannot do this I'm afraid - in general you cannot set a variable in one
recipe that will be read by another. See:

https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_change_how_my_recipe_is_built_depending_on_what_image_I.27m_building.3F

The only real way to do what you're looking for is to have two different
recipes (where the name is actually different, not just the version). e.g. you
could have myapp_git.bb and myapp-test_git.bb. You could use a common
.inc file and "require" that from both .bb files in order to keep the common
parts in one place. Then you can specify the corresponding package name
in each image recipe.

Cheers,
Paul



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

Re: [yocto] Setting recipe version inside an image recipe

[Paul Eggleton]

Hi Mauro

On Thursday, 19 July 2018 2:36:18 PM CEST Mauro Ziliani wrote:
> I'm working with Krogoth.
> 
> I'd like to do this.
> 
> - I have my application added to yocto tree by its own recipe myapp_git.bb
> 
> This recipe get the source code from a local git repository setting  
> SRCREV for the last stable application source code.
> 
> SRCREV is fixed in myapp_git.bb
> 
> 
> - I have the recipe for the final production image for the embedded  
> system  myos.bb, which declare
> 
> IMAGE_INSTALL_append = " myapp "
> 
> The myos.bb compiles myapp with the version declare in myapp_git.bb recipe
> 
> 
> I'd like to do that
> 
> - prepare a base recipe myos-base.inc  where I define all I need the 
> produce the final image with
> 
> IMAGE_INSTALL_append = " myapp "
> 
> - prepare myos.bb recipe where I can fix the version of myapp.bb to a 
> prpduction version
> 
> - prepare myos-test.bb recipre where I can fix the HEAD branch of git 
> from I can download the  latest source code for test.
> 
> 
> I try this
> 
> - inside myapp_git.bb I put SRCREV="${MYAPP_SRCREV}"
> 
> - inside myos.bb I set MYAPP_SRCREV="prodution-version-X" to download 
> the tag/branch production-version-X
> 
> - inside myos-test.bb I set MYAPP_SRCREV="${AUTOREV}" to download the 
> latest git commit

You cannot do this I'm afraid - in general you cannot set a variable in one
recipe that will be read by another. See:

https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_change_how_my_recipe_is_built_depending_on_what_image_I.27m_building.3F

The only real way to do what you're looking for is to have two different
recipes (where the name is actually different, not just the version). e.g. you
could have myapp_git.bb and myapp-test_git.bb. You could use a common
inc file and "require" that from both .bb files in order to keep the common
parts in one place. Then you can specify the corresponding package name
in each image recipe.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] cannelloni.bb (Was: [Chicken and Egg problem] Defining RDEPENDS of the package itself)

[Zoran Stojsavljevic]

> :-)  I mentioned that in my original response.

I noticed after I sent my email. Sorry/apologies, I do too many
different tasks, so I get very often scrambled. :-(

> I will finish up that response later anyway so we can figure out a good 
> strategy together.

Too many companies do this on their own, my best guess. VW, Audi, BMW,
Daimler Benz... And their partners.

Some better strategy (unification) would be well desired extras. :-)

Thank you,
Zoran
___

On Thu, Jul 19, 2018 at 2:50 PM, Gunnar Andersson  wrote:
> On Thu, 2018-07-19 at 14:44 +0200, Zoran Stojsavljevic wrote:
>> Actually, I ran into this:
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-
>> extended/socketcan
>
> :-)  I mentioned that in my original response.
>
>>
>> So here, I think, can-utils recipes should be revisited, cannelloni
>> recipe added, and also another application recipe added as well:
>> https://github.com/dschanoeh/socketcand/
>
> Great, you're answering some of the follow-up questions I had.  I need to
> task switch now, but I will finish up that response later anyway so we can
> figure out a good strategy together.
>
> - Gunnar
>
> --
> Gunnar Andersson 
> Development Lead
> GENIVI Alliance
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH 2/3] Add minimal tests for update script

[Paul Eggleton]

Up to this point we haven't had any regression tests for the layer
index, but the application (in particular the update script) has become
rather complicated, and we have had a few regressions, so here are some
tests. I've implemented them using pytest and pytest-django; I chose
pytest since we are starting from scratch here and I like the idea of
pytest's fixtures among other features. Annoyingly though because of our
use of separate scripts that need to perform database operations I had
to hack around some of the behaviour of pytest-django, which is clearly
not designed with this kind of structure in mind, but that's taken care
of now. Note that I've only considered backend testing for the moment,
there's not yet a strategy for testing the UI.

To run the tests you simply run "pytest" in the root of the repository.
You will need to have a working configuration set in settings.py (a
database needs to be set, but won't actually be used), and if you're
using MariaDB/MySQL then you'll need the READ COMMITTED transaction
isolation mode selected.

At the moment there are only a few basic tests for the update script
and a bunch of comments describing some we should add. The tests use
a newly added synthetic meta-layerindex-test layer on
git.yoctoproject.org so we can have something with known and fairly
static content. I expect we will extend these tests in the near future.

Signed-off-by: Paul Eggleton 
---
 .gitignore   |   1 +
 pytest.ini   |   4 +
 tests/test_update.py | 195 +++
 3 files changed, 200 insertions(+)
 create mode 100644 pytest.ini
 create mode 100644 tests/test_update.py

diff --git a/.gitignore b/.gitignore
index 0010cdb6..edfc2ac1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,5 @@
 *.pyc
 *.db3
 *.swp
+.pytest_cache
 venv/
diff --git a/pytest.ini b/pytest.ini
new file mode 100644
index ..c067b059
--- /dev/null
+++ b/pytest.ini
@@ -0,0 +1,4 @@
+[pytest]
+DJANGO_SETTINGS_MODULE = settings
+norecursedirs = .git layers
+
diff --git a/tests/test_update.py b/tests/test_update.py
new file mode 100644
index ..e00775d4
--- /dev/null
+++ b/tests/test_update.py
@@ -0,0 +1,195 @@
+# layerindex-web - tests for update script
+#
+# Copyright (C) 2018 Intel Corporation
+#
+# Licensed under the MIT license, see COPYING.MIT for details
+
+# NOTE: requires pytest-django. Run using "pytest" from the root
+# of the repository (add -s to avoid suppressing the output of commands
+# when working on the tests)
+
+# NOTE: for these tests to work with MySQL / MariaDB and Django 1.11, you will 
need
+# to set the transaction isolation mode to READ COMMITTED (basically set
+# transaction-isolation = READ-COMMITTED in the [mysqld] section of 
/etc/my.cnf)
+
+# NOTE: we cannot practically save and restore the database between tests 
(since
+# we want these tests to work with any database backend) nor use transactions
+# (since we need to launch the update script which uses a separate database
+# connection), thus these tests cannot depend upon eachother - i.e. they must
+# not touch the test layer(s) in a manner that would affect any other test. In
+# practice that means separate recipes for each test.
+
+import sys
+import os
+import shutil
+import subprocess
+import pytest
+
+basepath = os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))
+
+def run_cmd(cmd, cwd=None):
+if not cwd:
+cwd = basepath
+subprocess.check_call(cmd, stderr=subprocess.STDOUT, shell=True, cwd=cwd)
+
+@pytest.fixture(autouse=True)
+def enable_db_access_for_all_tests(db):
+pass
+
+@pytest.fixture
+def db_access_without_rollback_and_truncate(request, django_db_setup, 
django_db_blocker):
+django_db_blocker.unblock()
+request.addfinalizer(django_db_blocker.restore)
+
+@pytest.fixture(scope="module")
+def backup_settings(tmpdir_factory):
+stmpdir = tmpdir_factory.mktemp('settings')
+settingsfile = os.path.join(basepath, 'settings.py')
+backupfile = os.path.join(stmpdir, 'settings.bak')
+shutil.copy(settingsfile, backupfile)
+yield settingsfile
+shutil.copy(backupfile, settingsfile)
+
+@pytest.fixture(scope="module")
+def hack_settings(backup_settings):
+# It's horrific to have to do this, but we need to have additional
+# scripts connect to the testing database and not whatever's in settings.py
+# on disk right now, and this appears to be the only real way to do that
+from django.conf import settings
+with open(backup_settings, 'a') as f:
+f.write('\nDATABASES = %s\n' % settings.DATABASES)
+
+@pytest.fixture(scope="module")
+def import_layer(hack_settings):
+run_cmd("layerindex/tools/import_layer.py 
git://git.openembedded.org/openembedded-core -s meta openembedded-core")
+run_cmd("layerindex/tools/import_layer.py 
git://git.yoctoproject.org/meta-layerindex-test -s meta-layerindex-test")
+run_cmd("layerindex/update.py -l meta-layerindex-test")
+
+def test_example_recipe(impo

[yocto] [layerindex-web][PATCH 3/3] README: add an example virtualenv-based setup

[Paul Eggleton]

A while ago I was trying to help someone new get started with a
development setup for the layer index and it occurred to me that the
virtualenv-based environment I am using for development isn't actually
covered in the documentation, so I wrote something quick for them but
didn't do anything further with it until now. Here it is in more fleshed
out form for the README.

Also clarify the python requirements for the update script a little bit.

Signed-off-by: Paul Eggleton 
---
 README | 37 +++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 72dce71d..d1b1f9bd 100644
--- a/README
+++ b/README
@@ -29,8 +29,41 @@ In order to make use of this application you will need:
   in settings.py and have access to the database used by the web
   application):
   * Python 2.7.6+ / Python 3.4+ to match with the version of BitBake
-for the OpenEmbedded branch being parsed
-  * GitPython (python-git) version 2.0 or later
+for the OpenEmbedded branch being parsed (for modern versions it's
+Python 3.)
+  * Python dependencies as per requirements.txt (we still need Django
+etc. here since we interact with the database through Django's ORM.)
+
+Example virtualenv-based setup for the above:
+
+Python's virtualenv provides an easy way to isolate the python dependencies
+of applications such as the layer index. Here's an example of setting up a
+virtualenv for the layer index that's particularly useful for development.
+(This assumes a Debian-based distribution, adjust accordingly for other
+distros).
+
+1. Install required host distro packages (some of these are required by
+   pip to build the dependencies; it's also assumed you want MariaDB as
+   the database backend):
+
+   sudo apt-get install virtualenv libmariadb-client-lgpl-dev build-essential 
python3-dev libjpeg-dev libz-dev libfreetype6-dev mariadb-server rabbitmq-server
+
+2. Work around path issues (you may not need this):
+
+   sudo ln -s /usr/bin/mariadb_config /usr/bin/mysql_config
+
+3. Create a Python 3 virtualenv (path can be anywhere you like):
+
+   virtualenv -p python3 /path/to/desired/venv
+
+4. Activate the virtualenv:
+
+   . /path/to/desired/venv/bin/activate
+
+5. Install requirements:
+
+   pip install -r requirements.txt
+
 
 Setup instructions:
 
-- 
2.17.1

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

[yocto] [layerindex-web][PATCH 1/3] update: fix handling of moves outside of a layer

[Paul Eggleton]

If a file is moved (renamed) to a path outside of the layer, e.g.
another layer within a multi-layer repository, then we need to treat it
as a delete. Up until now we were updating the path and continuing, and
then the recipe was also picked up as an add in the other layer, leading
to duplicate recipe entries. I'd noticed these duplicates before but up
until now I'd thought that they were due to another bug we already
fixed, apparently not.

In order to remove these erroneous duplicate entries in existing
databases I have also added a layerindex/tools/fixup_duplicates.py
script. I've also made the -r/--reload option delete them as well.

Signed-off-by: Paul Eggleton 
---
 layerindex/tools/fixup_duplicates.py | 69 
 layerindex/update_layer.py   | 27 +++
 2 files changed, 87 insertions(+), 9 deletions(-)
 create mode 100644 layerindex/tools/fixup_duplicates.py

diff --git a/layerindex/tools/fixup_duplicates.py 
b/layerindex/tools/fixup_duplicates.py
new file mode 100644
index ..5abe2c2d
--- /dev/null
+++ b/layerindex/tools/fixup_duplicates.py
@@ -0,0 +1,69 @@
+#!/usr/bin/env python3
+
+# Fix recipes that were moved out
+#
+# Copyright (C) 2017 Intel Corporation
+# Author: Paul Eggleton 
+#
+# Licensed under the MIT license, see COPYING.MIT for details
+
+
+import sys
+import os
+
+sys.path.insert(0, os.path.realpath(os.path.join(os.path.dirname(__file__), 
'..')))
+
+import optparse
+import utils
+import logging
+
+class DryRunRollbackException(Exception):
+pass
+
+logger = utils.logger_create('LayerIndexFixup')
+
+
+
+def main():
+parser = optparse.OptionParser(
+usage = """
+%prog [options""")
+
+parser.add_option("-n", "--dry-run",
+help = "Don't write any data back to the database",
+action="store_true", dest="dryrun")
+parser.add_option("-d", "--debug",
+help = "Enable debug output",
+action="store_const", const=logging.DEBUG, dest="loglevel", 
default=logging.INFO)
+parser.add_option("-q", "--quiet",
+help = "Hide all output except error messages",
+action="store_const", const=logging.ERROR, dest="loglevel")
+
+options, args = parser.parse_args(sys.argv)
+
+utils.setup_django()
+import settings
+from layerindex.models import Recipe
+from django.db import transaction
+
+logger.setLevel(options.loglevel)
+
+try:
+with transaction.atomic():
+#LayerBranch.objects.filter(layermaintainer__isnull=True).delete()
+
#LayerItem.objects.filter(layerbranch__isnull=True).filter(classic=False).delete()
+
#LayerItem.objects.filter(layerbranch__isnull=True).filter(classic=False).delete()
+for recipe in Recipe.objects.filter(filepath__startswith='../'):
+print('Deleting erroneous recipe %s %s' % (recipe.layerbranch, 
recipe))
+recipe.delete()
+
+if options.dryrun:
+raise DryRunRollbackException()
+except DryRunRollbackException:
+pass
+
+sys.exit(0)
+
+
+if __name__ == "__main__":
+main()
diff --git a/layerindex/update_layer.py b/layerindex/update_layer.py
index d34d8a59..2b39e8ef 100644
--- a/layerindex/update_layer.py
+++ b/layerindex/update_layer.py
@@ -502,6 +502,10 @@ def main():
 if skip:
 continue
 if oldpath.startswith(subdir_start):
+if not newpath.startswith(subdir_start):
+logger.debug("Treating rename of %s to %s as a 
delete since new path is outside layer" % (oldpath, newpath))
+other_deletes.append(diffitem)
+continue
 (oldtypename, oldfilepath, oldfilename) = 
recipeparse.detect_file_type(oldpath, subdir_start)
 (newtypename, newfilepath, newfilename) = 
recipeparse.detect_file_type(newpath, subdir_start)
 if oldtypename != newtypename:
@@ -684,16 +688,21 @@ def main():
 # First, check which recipes still exist
 layerrecipe_values = layerrecipes.values('id', 
'filepath', 'filename', 'pn')
 for v in layerrecipe_values:
-root = os.path.join(layerdir, v['filepath'])
-fullpath = os.path.join(root, v['filename'])
-preserve = True
-if os.path.exists(fullpath):
-for removedir in removedirs:
-if fullpath.startswith(removedir):
-preserve = False
-break
-else:
+if v['filepath'].startswith('../'):
+# FIXME: The

[yocto] [layerindex-web][PATCH 0/3] Bugfix, tests, doc update

[Paul Eggleton]

A fix for a bug in the update script, some regression tests (finally!)
and a small bit for the README about setting up dependencies using
virtualenv.


The following changes since commit 49981aebf6fab9338f2a570acbb9aa67312c8865:

  Add site-wide notice support (2018-07-09 13:50:15 +0200)

are available in the Git repository at:

  git://git.yoctoproject.org/layerindex-web paule/fixes4
  http://git.yoctoproject.org/cgit.cgi//log/?h=paule/fixes4

Paul Eggleton (3):
  update: fix handling of moves outside of a layer
  Add minimal tests for update script
  README: add an example virtualenv-based setup

 .gitignore   |   1 +
 README   |  37 -
 layerindex/tools/fixup_duplicates.py |  69 ++
 layerindex/update_layer.py   |  27 ++--
 pytest.ini   |   4 +
 tests/test_update.py | 195 +++
 6 files changed, 322 insertions(+), 11 deletions(-)
 create mode 100644 layerindex/tools/fixup_duplicates.py
 create mode 100644 pytest.ini
 create mode 100644 tests/test_update.py

-- 
2.17.1

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

Re: [yocto] cannelloni.bb (Was: [Chicken and Egg problem] Defining RDEPENDS of the package itself)

[Gunnar Andersson]

On Thu, 2018-07-19 at 14:44 +0200, Zoran Stojsavljevic wrote:
> Actually, I ran into this:
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-
> extended/socketcan

:-)  I mentioned that in my original response.

> 
> So here, I think, can-utils recipes should be revisited, cannelloni
> recipe added, and also another application recipe added as well:
> https://github.com/dschanoeh/socketcand/

Great, you're answering some of the follow-up questions I had.  I need to
task switch now, but I will finish up that response later anyway so we can
figure out a good strategy together.

- Gunnar

-- 
Gunnar Andersson 
Development Lead
GENIVI Alliance

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

Re: [yocto] cannelloni.bb (Was: [Chicken and Egg problem] Defining RDEPENDS of the package itself)

[Zoran Stojsavljevic]

Actually, I ran into this:
http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/socketcan

So here, I think, can-utils recipes should be revisited, cannelloni
recipe added, and also another application recipe added as well:
https://github.com/dschanoeh/socketcand/

Best Regards,
Zoran

On Thu, Jul 19, 2018 at 1:09 PM, Zoran Stojsavljevic
 wrote:
>> I'm happy to move cannelloni to a generic layer if there is wider interest.
>
> I did not write only the stand-alone recipe for cannelloni, since I
> needed the one, original one from this location:
> https://github.com/mguentner/cannelloni
>
> I also wrote one for can-utils, since one, residing in YOCTO Projects
> from Pengutronix GIT is 8y old.
> I used one from here (most recent, I guess):
> https://github.com/linux-can/can-utils
>
> So, I created my own layer, and put them both (recipes) there.
>
> If you all ask me, I would like to have some generic CAN layer, where
> these CAN recipes can reside.
>
> There are more CAN user space creations, most of them work over
> socketCAN (and these days more important socketCAN-Fd) frameworks.
>
> This generic CAN layer creation will be the step toward the unified
> automotive system CAN architecture... IMHO.
>
> Zoran
> ___
>
>
> On Thu, Jul 19, 2018 at 12:41 PM, Gunnar Andersson
>  wrote:
>> On Wed, 2018-07-18 at 23:49 +0200, Mirza Krak wrote:
>>> On Wed, Jul 18, 2018, 13:38 Zoran Stojsavljevic >> .com> wrote:
>>> > Hello YOCTO community,
>>> >
>>> > Since I need to build the latest and the greatest Github creations
>>> > from the independent contributors, I decided myself to write few YOCTO
>>> > recipes and to get myself to this (un)pleasant learning path.
>>> >
>>> > I did few examples, simplistic ones, before I took more complex
>>> > recipes to write.
>>> >
>>> > And... I need this one, Cannelloni, one defined here:
>>> > https://github.com/mguentner/cannelloni
>>>
>>> Recipe for above can be found here, https://github.com/GENIVI/genivi-dev-
>>> platform/blob/master/meta-genivi-dev/meta-genivi-dev/recipes-
>>> extended/cannelloni/cannelloni.bb.
>>
>> Since that layer is not kept as a separate submodule, your only reasonable
>> option would be copying, so I'll jump in to preempt that.
>>
>> It would be better with a single location (shared maintenance).  meta-
>> genivi-dev is where we keep things that (seem to be so far) unique to our
>> platform, so rather than recommending to reuse that layer we strive to push
>> things out of there, as soon as it makes sense.
>>
>> I'm happy to move cannelloni to a generic layer if there is wider interest.
>>
>> meta-can-networking?  There might be some other CAN associated components of
>> interest so that it does not become one of those single-recipe layers...
>>
>> On the other hand, some related things are elsewhere:
>>
>> - meta-openembedded/meta-oe/recipes-extended/socketcan/*
>>
>> Please share your thoughts.
>>
>> - Gunnar
>>
>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Setting recipe version inside an image recipe

[Mauro Ziliani]

Hi all

I'm working with Krogoth.

I'd like to do this.

- I have my application added to yocto tree by its own recipe myapp_git.bb

This recipe get the source code from a local git repository setting  
SRCREV for the last stable application source code.


SRCREV is fixed in myapp_git.bb


- I have the recipe for the final production image for the embedded  
system  myos.bb, which declare


IMAGE_INSTALL_append = " myapp "

The myos.bb compiles myapp with the version declare in myapp_git.bb recipe


I'd like to do that

- prepare a base recipe myos-base.inc  where I define all I need the 
produce the final image with


IMAGE_INSTALL_append = " myapp "

- prepare myos.bb recipe where I can fix the version of myapp.bb to a 
prpduction version


- prepare myos-test.bb recipre where I can fix the HEAD branch of git 
from I can download the  latest source code for test.



I try this

- inside myapp_git.bb I put SRCREV="${MYAPP_SRCREV}"

- inside myos.bb I set MYAPP_SRCREV="prodution-version-X" to download 
the tag/branch production-version-X


- inside myos-test.bb I set MYAPP_SRCREV="${AUTOREV}" to download the 
latest git commit




Any idea?


MZ

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

Re: [yocto] [Chicken and Egg problem] Defining RDEPENDS of the package itself!

[Zoran Stojsavljevic]

> Is your code published? (I mean not in the email,
> too messy to extract it from there)

Feel free to comment on it, and to elaborate better recipes. Published
on my scratch pad everything/nothing git:
https://github.com/ZoranStojsavljevic/cip-rt-misc/tree/master/configs/bbb/YOCTO-recipes

Zoran
___


On Thu, Jul 19, 2018 at 12:51 PM, Gunnar Andersson
 wrote:
> On Thu, 2018-07-19 at 09:22 +0200, Zoran Stojsavljevic wrote:
>
> [trimmed]
>
>> Actually, the recipe I am showing here is the GENIVI (the same you
>> pointed to), but heavily modified. :-)
>
> See previous email about shared maintenance :-)
>
> Is your code published? (I mean not in the email, too messy to extract it
> from there)
>
> - Gunnar
>
> --
> Gunnar Andersson 
> Development Lead
> GENIVI Alliance
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cannelloni.bb (Was: [Chicken and Egg problem] Defining RDEPENDS of the package itself)

[Zoran Stojsavljevic]

> I'm happy to move cannelloni to a generic layer if there is wider interest.

I did not write only the stand-alone recipe for cannelloni, since I
needed the one, original one from this location:
https://github.com/mguentner/cannelloni

I also wrote one for can-utils, since one, residing in YOCTO Projects
from Pengutronix GIT is 8y old.
I used one from here (most recent, I guess):
https://github.com/linux-can/can-utils

So, I created my own layer, and put them both (recipes) there.

If you all ask me, I would like to have some generic CAN layer, where
these CAN recipes can reside.

There are more CAN user space creations, most of them work over
socketCAN (and these days more important socketCAN-Fd) frameworks.

This generic CAN layer creation will be the step toward the unified
automotive system CAN architecture... IMHO.

Zoran
___


On Thu, Jul 19, 2018 at 12:41 PM, Gunnar Andersson
 wrote:
> On Wed, 2018-07-18 at 23:49 +0200, Mirza Krak wrote:
>> On Wed, Jul 18, 2018, 13:38 Zoran Stojsavljevic > .com> wrote:
>> > Hello YOCTO community,
>> >
>> > Since I need to build the latest and the greatest Github creations
>> > from the independent contributors, I decided myself to write few YOCTO
>> > recipes and to get myself to this (un)pleasant learning path.
>> >
>> > I did few examples, simplistic ones, before I took more complex
>> > recipes to write.
>> >
>> > And... I need this one, Cannelloni, one defined here:
>> > https://github.com/mguentner/cannelloni
>>
>> Recipe for above can be found here, https://github.com/GENIVI/genivi-dev-
>> platform/blob/master/meta-genivi-dev/meta-genivi-dev/recipes-
>> extended/cannelloni/cannelloni.bb.
>
> Since that layer is not kept as a separate submodule, your only reasonable
> option would be copying, so I'll jump in to preempt that.
>
> It would be better with a single location (shared maintenance).  meta-
> genivi-dev is where we keep things that (seem to be so far) unique to our
> platform, so rather than recommending to reuse that layer we strive to push
> things out of there, as soon as it makes sense.
>
> I'm happy to move cannelloni to a generic layer if there is wider interest.
>
> meta-can-networking?  There might be some other CAN associated components of
> interest so that it does not become one of those single-recipe layers...
>
> On the other hand, some related things are elsewhere:
>
> - meta-openembedded/meta-oe/recipes-extended/socketcan/*
>
> Please share your thoughts.
>
> - Gunnar
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Chicken and Egg problem] Defining RDEPENDS of the package itself!

[Gunnar Andersson]

On Thu, 2018-07-19 at 09:22 +0200, Zoran Stojsavljevic wrote:

[trimmed]

> Actually, the recipe I am showing here is the GENIVI (the same you
> pointed to), but heavily modified. :-)

See previous email about shared maintenance :-)

Is your code published? (I mean not in the email, too messy to extract it
from there)

- Gunnar

-- 
Gunnar Andersson 
Development Lead
GENIVI Alliance


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

[yocto] cannelloni.bb (Was: [Chicken and Egg problem] Defining RDEPENDS of the package itself)

[Gunnar Andersson]

On Wed, 2018-07-18 at 23:49 +0200, Mirza Krak wrote:
> On Wed, Jul 18, 2018, 13:38 Zoran Stojsavljevic  .com> wrote:
> > Hello YOCTO community,
> > 
> > Since I need to build the latest and the greatest Github creations
> > from the independent contributors, I decided myself to write few YOCTO
> > recipes and to get myself to this (un)pleasant learning path.
> > 
> > I did few examples, simplistic ones, before I took more complex
> > recipes to write.
> > 
> > And... I need this one, Cannelloni, one defined here:
> > https://github.com/mguentner/cannelloni
> 
> Recipe for above can be found here, https://github.com/GENIVI/genivi-dev-
> platform/blob/master/meta-genivi-dev/meta-genivi-dev/recipes-
> extended/cannelloni/cannelloni.bb. 

Since that layer is not kept as a separate submodule, your only reasonable
option would be copying, so I'll jump in to preempt that.  

It would be better with a single location (shared maintenance).  meta-
genivi-dev is where we keep things that (seem to be so far) unique to our
platform, so rather than recommending to reuse that layer we strive to push
things out of there, as soon as it makes sense.

I'm happy to move cannelloni to a generic layer if there is wider interest.

meta-can-networking?  There might be some other CAN associated components of
interest so that it does not become one of those single-recipe layers...

On the other hand, some related things are elsewhere:

- meta-openembedded/meta-oe/recipes-extended/socketcan/*

Please share your thoughts.

- Gunnar



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

Re: [yocto] Why can diffsigs take sometimes really looooong?

[Richard Purdie]

On Mon, 2018-07-16 at 11:26 +0300, Uwe Geuder wrote:
> On Sun, Jul 15, 2018 at 1:38 PM, Richard Purdie  wrote:
> > On Fri, 2018-07-13 at 19:18 +0300, Uwe Geuder wrote:
> > > At times I find the diffsigs command useful/educational to
> > > understand
> > > what is going on in my build.
> > > 
> > > $ bitbake-diffsigs -t myimage do_image
> > > 
> > > Often the result is shown in no time. However, recently I got
> > > some
> > > cases were it takes 150 (!) minutes to show a simple difference
> > > (1
> > > line
> > > changed in do_install of systemd).
> > > 
> > > In comparision building after that change (with sstate) takes
> > > some 10
> > > minutes. And building everything from scratch (no sstate) takes
> > > just
> > > a
> > > bit over 50 minutes on the same machine.
> > > 
> > > Of course the build can make good use of my 8 cores / 16 threads,
> > > whereas diffsigs seems to run in only 1 core. Still, shouldn't
> > > every
> > > build calculate all the dependencies, so running diffsigs should
> > > only
> > > be
> > > a small fraction of that work?
> > > 
> > > Is there a natural explanation why diffsigs can sometimes be so
> > > slow?
> > > Just curious to understand what is going on there.
> > > 
> > > I am on Rocko 2.4.3 if that makes a difference.
> > 
> > Is your sstate directory on something slow like NFS?
> > 
> 
> No, it is on the same ext4 as the rest of my build area. Backed by an
> Intel NVMe flash drive, so hopefully that is of reasonable quality...
> 
> Here is the output of the time command from a new "record" diffsigs
> run
> shortly after my first posting
> 
> > real244m8.594s
> > user137m21.897s
> > sys 8m17.606s
> 
> So there is already more than 2 hours of CPU usage. Because diffsigs
> seems to be single threaded, that is a lower bound even with the best
> filesystem/disk.
> 
> This build environment has been in use in development work for a
> couple of days. So there are many different signatures. But that
> should not make any significant difference if I compare just the 2
> last ones, should it?
> 
> When I had such a long run for the first time I first thought I had
> run in an endless loop. strace showed that the same files were opened
> again and again. However, in the end the command completed. I haven't
> made an effort yet to understand the pattern how it opens these
> files.
> 
> For clean builds with no previous sstate I need "only" something like
> 
> > real54m53.939s
> > user 3268446 - 103936 = 3164510 = 527m25.10s
> > system 820431 - 1345 = 136m30.86s
> 
> (These numbers are from overlayfs over ext4 on the same disk. Don't
> have
> any numbers without the additional overlayfs handy right now.
> According
> to experience the additional overlayfs leads to very similar wall
> times,
> just significant extra system CPU time)

Based on the above info, it seems there is something scaling badly in
whatever algorithm that code is using :(

I don't remember much about that code in particular, I do know I've
never been happy with its chances of successfully reporting what the
user actually wanted to know. Its been on my todo list for a while to
go back and try and create a command which actually gives the user the
information they wanted but there have been other more pressing
issues...

I'd certainly be interested in understanding where the current code is
scaling badly...

Cheers,

Richard



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

[yocto] QA cycle report for 2.2.4 RC1

[Yeoh, Ee Peng]

Hello All,
 
This is the full report for 2.2.4.rc1:  
https://wiki.yoctoproject.org/wiki/WW28_-_2018-07-13_-_Full_Test_Cycle_2.2.4_rc1
 
=== Summary 
 
All planned tests were executed.  There were zero high milestone defect.  Team 
had found 3 new defects [1] [2] [3] where runtime test_parselogs testcase 
failed with error message inside dmesg log.  While executing the runtime smart 
package manager tests on target platform to install psplash, team discovered 
that the target platform screen was splash with Yocto logo and the Yocto logo 
remain after the tests completed, need further investigation to verify if this 
was caused by post installation script from psplash.  For performance test, 
regression on 2.2.3.rc2 faced with error where SRCREV defined for distcc was no 
longer available.  For pTest, both glib-2.0 and util-linux passrate decreased 
as compared to 2.2.3.rc2 as some new tests available in 2.2.4.rc1 were failing. 
  
 
=== QA-Hints
 
Found 3 non critical defects.  
 
=== Bugs 
 
New Bugs
[1] Bug 12854 - [2.2.4.rc1][BSP Auto] [genericx86-64 on MMAX64bit] 
[test_parselogs] blk_update_request: I/O error, dev loop0
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12854

[2] Bug 12853 - [2.2.4.rc1][BSP Auto] [genericx86-64 on NUC6][test_parselogs] 
drm:intel_dp_link_training_clock_recovery] *ERROR* too many voltage retries, 
give up
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12853

[3] Bug 12852 - [2.2.4.rc1][BSP Auto] [genericx86-64-WIC on 
NUC6][test_parselogs] snd_hda_intel :00:1f.3: failed to add i915 component 
master  
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12852

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

Re: [yocto] [Chicken and Egg problem] Defining RDEPENDS of the package itself!

[Zoran Stojsavljevic]

This does work:

S = "${WORKDIR}/git"

inherit pkgconfig cmake
inherit systemd

EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=Release"

INSANE_SKIP_${PN} = "ldflags"
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_SYSROOT_STRIP = "1"
SOLIBS = ".so"
FILES_SOLIBSDEV = ""

do_install_*append* () {
install -d ${D}${libdir}
install -m 0755 ${WORKDIR}/*build/*libcannelloni-common.so ${D}${libdir}
}

Thank you all for help!
Zoran Stojsavljevic

On Thu, Jul 19, 2018 at 9:22 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Andre,
>
> Thank you for the tips.
>
> Tried what you have suggested. I had some errors, again in
> do_install(), then I read .log, and fixed the paths.
>
> This is my recipe, important part of it, as of now:
> ___
>
> S = "${WORKDIR}/git"
>
> inherit pkgconfig cmake
> inherit systemd
>
> EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=Release"
>
> INSANE_SKIP_${PN} = "ldflags"
> INHIBIT_PACKAGE_STRIP = "1"
> INHIBIT_SYSROOT_STRIP = "1"
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
> do_install () {
> install -d ${D}${libdir}
> install -m 0755 cannelloni ${D}${bindir}
> install -m 0755 ${WORKDIR}/build/libcannelloni-common.so ${D}${libdir}
> }
> ___
>
> Where I modified install directories. ${libdir} is /usr/lib (instead
> /usr/local/lib), all cool with this one as well.
>
> (I guess, I could use LOCAL_LIB =  "/usr/local/lib", and then change
> ${libdir} with ${LOCAL_LIB})
>
> I went further with bitbake. Now I am failing in do_package()
> (inherited from default), with the following ERRORs:
>
> ERROR: cannelloni-1.0-r0 do_package: QA Issue: cannelloni:
> Files/directories were installed but not shipped in any package:
>   /usr/bin
> Please set FILES such that these items are packaged. Alternatively if
> they are unneeded, avoid installing them or delete them within
> do_install.
> cannelloni: 1 installed and not shipped files. [installed-vs-shipped]
> ERROR: cannelloni-1.0-r0 do_package: Fatal QA errors found, failing task.
> ERROR: cannelloni-1.0-r0 do_package: Function failed: do_package
> ERROR: Logfile of failure stored in:
> /home/netmodule.intranet/stojsavljevic/projects/
> beaglebone-black/yocto-rocko/poky/build/tmp/work/
> cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/
> temp/log.do_package.3501
> ERROR: Task (/home/netmodule.intranet/stojsavljevic/projects/
> beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-
> canapp/cannelloni/cannelloni.bb:do_package)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 535 tasks of which 524 didn't need to
> be rerun and 1 failed.
>
> Any take on that?
> ___
>
> Mirza,
>
> Actually, the recipe I am showing here is the GENIVI (the same you
> pointed to), but heavily modified. :-)
>
> And, yes, I am using latest sumo.
>
> Thank you all,
> Zoran
> ___
>
> On Wed, Jul 18, 2018 at 7:06 PM, Andre McCurdy 
> wrote:
> > On Wed, Jul 18, 2018 at 7:04 AM, Zoran Stojsavljevic
> >  wrote:
> >> Yep. Did it. Some symlink is missing (I guess, symlink to
> >> /usr/local/lib/libcannelloni-common.so???
> >>
> >> Initialising tasks: 100%
> >> |###
> 
> ##|
> >> Time: 0:00:00
> >> NOTE: Executing SetScene Tasks
> >> NOTE: Executing RunQueue Tasks
> >> ERROR: cannelloni-1.0-r0 do_package_qa: QA Issue: cannelloni rdepends on
> >> cannelloni-dev [dev-deps]
> >> ERROR: cannelloni-1.0-r0 do_package_qa: QA Issue: -dev package contains
> >> non-symlink .so: cannelloni-dev path
> >> '/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-
> r0/packages-split/cannelloni-dev/usr/lib/libcannelloni-common.so'
> >> [dev-elf]
> >> ERROR: cannelloni-1.0-r0 do_package_qa: QA run found fatal errors.
> Please
> >> consider fixing them.
> >> ERROR: cannelloni-1.0-r0 do_package_qa: Function failed: do_package_qa
> >> ERROR: Logfile of failure stored in:
> >> /home/netmodule.intranet/stojsavljevic/projects/
> beaglebone-black/yocto-rocko/poky/build/tmp/work/
> cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/
> temp/log.do_package_qa.7896
> >> ERROR: Task
> >> (/home/netmodule.intranet/stojsavljevic/projects/
> beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-
> canapp/cannelloni/cannelloni.bb:do_package_qa)
> >> failed with exit code '1'
> >> NOTE: Tasks Summary: Attempted 539 tasks of which 532 didn't need to be
> >> rerun and 1 failed.
> >>
> >> Summary: 1 task failed:
> >>
> >> /home/netmodule.intranet/stojsavljevic/projects/
> beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-
> canapp/cannelloni/cannelloni.bb:do_package_qa
> >> Summary: There were 2 WARNING messages shown.
> >> Summary: There were 4 ERROR messages shown, returning a non-zero exit
> code.
> >>
> >> How I can add this symlink (!) to this recipe?
> >
> > The error says "-dev package contains non-symlink .so".
> >
> > Simply adding a symlink somewhere will not help. The fix is to ensure
> > that libcannel

Re: [yocto] [Chicken and Egg problem] Defining RDEPENDS of the package itself!

[Zoran Stojsavljevic]

Hello Andre,

Thank you for the tips.

Tried what you have suggested. I had some errors, again in
do_install(), then I read .log, and fixed the paths.

This is my recipe, important part of it, as of now:
___

S = "${WORKDIR}/git"

inherit pkgconfig cmake
inherit systemd

EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=Release"

INSANE_SKIP_${PN} = "ldflags"
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_SYSROOT_STRIP = "1"
SOLIBS = ".so"
FILES_SOLIBSDEV = ""

do_install () {
install -d ${D}${libdir}
install -m 0755 cannelloni ${D}${bindir}
install -m 0755 ${WORKDIR}/build/libcannelloni-common.so ${D}${libdir}
}
___

Where I modified install directories. ${libdir} is /usr/lib (instead
/usr/local/lib), all cool with this one as well.

(I guess, I could use LOCAL_LIB =  "/usr/local/lib", and then change
${libdir} with ${LOCAL_LIB})

I went further with bitbake. Now I am failing in do_package()
(inherited from default), with the following ERRORs:

ERROR: cannelloni-1.0-r0 do_package: QA Issue: cannelloni:
Files/directories were installed but not shipped in any package:
  /usr/bin
Please set FILES such that these items are packaged. Alternatively if
they are unneeded, avoid installing them or delete them within
do_install.
cannelloni: 1 installed and not shipped files. [installed-vs-shipped]
ERROR: cannelloni-1.0-r0 do_package: Fatal QA errors found, failing task.
ERROR: cannelloni-1.0-r0 do_package: Function failed: do_package
ERROR: Logfile of failure stored in:
/home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/temp/log.do_package.3501
ERROR: Task 
(/home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-canapp/cannelloni/cannelloni.bb:do_package)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 535 tasks of which 524 didn't need to
be rerun and 1 failed.

Any take on that?
___

Mirza,

Actually, the recipe I am showing here is the GENIVI (the same you
pointed to), but heavily modified. :-)

And, yes, I am using latest sumo.

Thank you all,
Zoran
___

On Wed, Jul 18, 2018 at 7:06 PM, Andre McCurdy  wrote:
> On Wed, Jul 18, 2018 at 7:04 AM, Zoran Stojsavljevic
>  wrote:
>> Yep. Did it. Some symlink is missing (I guess, symlink to
>> /usr/local/lib/libcannelloni-common.so???
>>
>> Initialising tasks: 100%
>> |#|
>> Time: 0:00:00
>> NOTE: Executing SetScene Tasks
>> NOTE: Executing RunQueue Tasks
>> ERROR: cannelloni-1.0-r0 do_package_qa: QA Issue: cannelloni rdepends on
>> cannelloni-dev [dev-deps]
>> ERROR: cannelloni-1.0-r0 do_package_qa: QA Issue: -dev package contains
>> non-symlink .so: cannelloni-dev path
>> '/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni-dev/usr/lib/libcannelloni-common.so'
>> [dev-elf]
>> ERROR: cannelloni-1.0-r0 do_package_qa: QA run found fatal errors. Please
>> consider fixing them.
>> ERROR: cannelloni-1.0-r0 do_package_qa: Function failed: do_package_qa
>> ERROR: Logfile of failure stored in:
>> /home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/temp/log.do_package_qa.7896
>> ERROR: Task
>> (/home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-canapp/cannelloni/cannelloni.bb:do_package_qa)
>> failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 539 tasks of which 532 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>
>> /home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-canapp/cannelloni/cannelloni.bb:do_package_qa
>> Summary: There were 2 WARNING messages shown.
>> Summary: There were 4 ERROR messages shown, returning a non-zero exit code.
>>
>> How I can add this symlink (!) to this recipe?
>
> The error says "-dev package contains non-symlink .so".
>
> Simply adding a symlink somewhere will not help. The fix is to ensure
> that libcannelloni-common.so gets packaged in the main run-time
> package (and not in the -dev package).
>
> Reading the section about non-versioned shared libraries here might help:
>
>   
> https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto