Re: [OE-core] [yocto] RFC: Improving the developer workflow

[Mike Looijmans]

On 08/07/2014 03:05 PM, Paul Eggleton wrote:

On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:

Historically I, and I suspect others, have done full image updates of
the storage medium,  onboard flash or whatever but these images are
getting so big now that I am trying to  move away from that and into
using package feeds for updates to embedded targets.


Personally with how fragile package management can end up being, I'm convinced
that full-image updates are the way to go for a lot of cases, but ideally with
some intelligence so that you only ship the changes (at a filesystem level
rather than a package or file level). This ensures that an upgraded image on
one device ends up exactly identical to any other device including a newly
deployed one. Of course it does assume that you have a read-only rootfs and
keep your configuration data / logs / other writeable data on a separate
partition or storage medium. However, beyond improvements to support for
having a read-only rootfs we haven't really achieved anything in terms of out-
of-the-box support for this, mainly due to lack of resources.


Full-image upgrades are probably most seen in "lab" environments, where 
the software is being developed.


Once deployed to customers, who will not be using a build system, the 
system must rely on packages and online updates.


Embedded systems look more like desktops these days.

- End-users will make changes to the system:
- "plugins" and other applications.
- configuration data
- application data (e.g. loggings, EPG data)
- There is not enough room in the flash for two full images.
- There is usually a virtually indestructable bootloader that can 
recover even from fully erasing the NAND flash.
- Flash filesystems are usually NAND. NAND isn't suitable for read-only 
root filesystems, you want to wear-level across the whole flash.


For the OpenPLi settop boxes we've been using "online upgrades" which 
basically just call "opkg update && opkg upgrade" for many years, and 
there's never been a real disaster. The benefits easily outweigh the 
drawbacks.


When considering system upgrades, too much attention is being spent in 
the "corner cases". It's not really a problem if the box is bricked when 
the power fails during an upgrade. As long as there's a procedure the 
end-user can use to recover the system (on most settop boxes, debricking 
the system is just a matter of inserting a USB stick and flipping the 
power switch).




--
Mike Looijmans
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] nssmyhostname: fix runtime dependencies

[Koen Kooi]

This should fix:

19:40  ERROR: Unable to install packages. Command 
'/mnt/ci_build/workspace/tmp/sysroots/x86_64-linux/usr/bin/opkg-cl -f 
/mnt/ci_build/workspace/tmp/work/genericarmv8-oe-linux/linaro-image-minimal/1.0-r0/opkg.conf
 -o
 
/mnt/ci_build/workspace/tmp/work/genericarmv8-oe-linux/linaro-image-minimal/1.0-r0/rootfs
 --force_postinstall --prefer-arch-to-version   install opkg-collateral stress 
libnss-myhostname2 run-postinsts auto-serial-console
 util-linux-fsck stress-dbg packagegroup-co
19:41  sed: can't read 
/mnt/ci_build/workspace/tmp/work/aarch64-oe-linux/nss-myhostname/0.3-r0/image/etc/nsswitch.conf:
 No such file or directory

Signed-off-by: Koen Kooi 
---
 meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb 
b/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
index d8ec863..b9ddeaf 100644
--- a/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
+++ b/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
@@ -13,6 +13,9 @@ SRC_URI[sha256sum] = 
"2ba744ea8d578d1c57c85884e94a3042ee17843a5294434d3a7f6c4d67
 
 inherit autotools
 
+# /etc/nsswitch.conf needs to be present
+RDEPENDS_${PN} = "base-files"
+
 pkg_postinst_${PN} () {
sed -e '/^hosts:/s/\s*\//' \
-e 's/\(^hosts:.*\)\(\\)\(.*\)\(\\)\(.*\)/\1\2 
myhostname \3\4\5/' \
-- 
1.9.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC][PATCH 2/2] systemd: rprovide/rreplace/rconflict nss-myhostname

[Koen Kooi]

Systems builds and packages nss-myhostname so add the appropriate lines to the 
recipe.

Signed-off-by: Koen Kooi 
---

I'm not 100% sure how this works with the debian shlib renaming for 
nss-myhostname_0.3.bb and how to handle this in the default providers include. 
Hence the RFC.


 meta/recipes-core/systemd/systemd_213.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_213.bb 
b/meta/recipes-core/systemd/systemd_213.bb
index 4fb7ffc..8572dbd 100644
--- a/meta/recipes-core/systemd/systemd_213.bb
+++ b/meta/recipes-core/systemd/systemd_213.bb
@@ -6,7 +6,11 @@ LIC_FILES_CHKSUM = 
"file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
 
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c \
 file://LICENSE.MIT;md5=544799d0b492f119fa04641d1b8868ed"
 
-PROVIDES = "udev"
+MYHOSTNAME = "nss-myhostname"
+# See EXTRA_OECONF_uclibc below
+MYHOSTNAME_uclibc = ""
+
+PROVIDES = "udev ${MYHOSTNAME}"
 
 PE = "1"
 
@@ -195,6 +199,10 @@ RRECOMMENDS_${PN}-binfmt = "kernel-module-binfmt-misc"
 
 RRECOMMENDS_${PN}-vconsole-setup = "kbd kbd-consolefonts"
 
+RPROVIDES_{$PN} = "${MYHOSTNAME}"
+RREPLACES_${PN} = "${MYHOSTNAME}"
+RCONFLICTS_${PN} = "${MYHOSTNAME}"
+
 CONFFILES_${PN} = "${sysconfdir}/systemd/journald.conf \
 ${sysconfdir}/systemd/logind.conf \
 ${sysconfdir}/systemd/system.conf \
-- 
1.9.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] RFC: Improving the developer workflow

[Alex J Lennon]

On 09/08/2014 09:13, Mike Looijmans wrote:
> On 08/07/2014 03:05 PM, Paul Eggleton wrote:
>> On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:
>>> Historically I, and I suspect others, have done full image updates of
>>> the storage medium,  onboard flash or whatever but these images are
>>> getting so big now that I am trying to  move away from that and into
>>> using package feeds for updates to embedded targets.
>>
>> Personally with how fragile package management can end up being, I'm
>> convinced
>> that full-image updates are the way to go for a lot of cases, but
>> ideally with
>> some intelligence so that you only ship the changes (at a filesystem
>> level
>> rather than a package or file level). This ensures that an upgraded
>> image on
>> one device ends up exactly identical to any other device including a
>> newly
>> deployed one. Of course it does assume that you have a read-only
>> rootfs and
>> keep your configuration data / logs / other writeable data on a separate
>> partition or storage medium. However, beyond improvements to support for
>> having a read-only rootfs we haven't really achieved anything in
>> terms of out-
>> of-the-box support for this, mainly due to lack of resources.
>
> Full-image upgrades are probably most seen in "lab" environments,
> where the software is being developed.
>
> Once deployed to customers, who will not be using a build system, the
> system must rely on packages and online updates.
>
> Embedded systems look more like desktops these days.
>
> - End-users will make changes to the system:
> - "plugins" and other applications.
> - configuration data
> - application data (e.g. loggings, EPG data)
> - There is not enough room in the flash for two full images.
> - There is usually a virtually indestructable bootloader that can
> recover even from fully erasing the NAND flash.
> - Flash filesystems are usually NAND. NAND isn't suitable for
> read-only root filesystems, you want to wear-level across the whole
> flash.
>

Agreeing with much you say Mike, I was under the impression that there
are block management layers now which will wear level across partitions?

So you could have your read only partition but still wear levelled
across the NAND ?

> For the OpenPLi settop boxes we've been using "online upgrades" which
> basically just call "opkg update && opkg upgrade" for many years, and
> there's never been a real disaster. The benefits easily outweigh the
> drawbacks.
>
> When considering system upgrades, too much attention is being spent in
> the "corner cases". It's not really a problem if the box is bricked
> when the power fails during an upgrade. As long as there's a procedure
> the end-user can use to recover the system (on most settop boxes,
> debricking the system is just a matter of inserting a USB stick and
> flipping the power switch).
>
>

For us on this latest project - and indeed the past few projects - it is
a major problem (and cost) if the device is bricked. These devices are
not user-maintainable and we'd be sending engineers out around the world
to fix.

Not a good impression to make with the customers either.

Whether we're a usual use case I don't know.

Cheers,

Alex

-- 

Dynamic Devices Ltd 

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin  Skype


This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/4] oeqa/utils/targetbuild.py: add support for sdk tests

[Corneliu Stoicescu]

- Create new abstract class BuildProject that provides basic functionality for 
a project/package building class
* contains abstract method _run() that needs to be implemented by all 
extending classes.
- The old TargetBuildProject class now extends the abstract BuildProjct class
- Introducing new SDKBuildProject that extends the abstract BuildProjct class

NOTE: Original patch made by: Richard Purdie 


Signed-off-by: Corneliu Stoicescu 
---
 meta/lib/oeqa/utils/targetbuild.py | 94 --
 1 file changed, 79 insertions(+), 15 deletions(-)

diff --git a/meta/lib/oeqa/utils/targetbuild.py 
b/meta/lib/oeqa/utils/targetbuild.py
index 3229676..eeb08ba 100644
--- a/meta/lib/oeqa/utils/targetbuild.py
+++ b/meta/lib/oeqa/utils/targetbuild.py
@@ -6,23 +6,25 @@
 
 import os
 import re
+import bb.utils
 import subprocess
+from abc import ABCMeta, abstractmethod
 
+class BuildProject():
 
-class TargetBuildProject():
+__metaclass__ = ABCMeta
 
-def __init__(self, target, d, uri, foldername=None):
-self.target = target
+def __init__(self, d, uri, foldername=None, tmpdir="/tmp/"):
 self.d = d
 self.uri = uri
-self.targetdir = "~/"
 self.archive = os.path.basename(uri)
-self.localarchive = "/tmp/" + self.archive
+self.localarchive = os.path.join(tmpdir,self.archive)
 self.fname = re.sub(r'.tar.bz2|tar.gz$', '', self.archive)
 if foldername:
 self.fname = foldername
 
-def download_archive(self):
+# Download self.archive to self.localarchive
+def _download_archive(self):
 
 exportvars = ['HTTP_PROXY', 'http_proxy',
   'HTTPS_PROXY', 'https_proxy',
@@ -41,6 +43,38 @@ class TargetBuildProject():
 cmd = cmd + "wget -O %s %s" % (self.localarchive, self.uri)
 subprocess.check_call(cmd, shell=True)
 
+# This method should provide a way to run a command in the desired 
environment.
+@abstractmethod
+def _run(self, cmd):
+pass
+
+# The timeout parameter of target.run is set to 0 to make the ssh command
+# run with no timeout.
+def run_configure(self, configure_args=''):
+return self._run('cd %s; ./configure %s' % (self.targetdir, 
configure_args))
+
+def run_make(self, make_args=''):
+return self._run('cd %s; make %s' % (self.targetdir, make_args))
+
+def run_install(self, install_args=''):
+return self._run('cd %s; make install %s' % (self.targetdir, 
install_args))
+
+def clean(self):
+self._run('rm -rf %s' % self.targetdir)
+subprocess.call('rm -f %s' % self.localarchive, shell=True)
+pass
+
+class TargetBuildProject(BuildProject):
+
+def __init__(self, target, d, uri, foldername=None):
+self.target = target
+self.targetdir = "~/"
+BuildProject.__init__(self, d, uri, foldername, tmpdir="/tmp")
+
+def download_archive(self):
+
+self._download_archive()
+
 (status, output) = self.target.copy_to(self.localarchive, 
self.targetdir)
 if status != 0:
 raise Exception("Failed to copy archive to target, output: %s" % 
output)
@@ -54,15 +88,45 @@ class TargetBuildProject():
 
 # The timeout parameter of target.run is set to 0 to make the ssh command
 # run with no timeout.
-def run_configure(self):
-return self.target.run('cd %s; ./configure' % self.targetdir, 0)[0]
+def _run(self, cmd):
+return self.target.run(cmd, 0)[0]
 
-def run_make(self):
-return self.target.run('cd %s; make' % self.targetdir, 0)[0]
 
-def run_install(self):
-return self.target.run('cd %s; make install' % self.targetdir, 0)[0]
+class SDKBuildProject(BuildProject):
+
+def __init__(self, testpath, sdkenv, d, uri, foldername=None):
+self.sdkenv = sdkenv
+self.testdir = testpath
+self.targetdir = testpath
+bb.utils.mkdirhier(testpath)
+self.datetime = d.getVar('DATETIME', True)
+self.testlogdir = d.getVar("TEST_LOG_DIR", True)
+bb.utils.mkdirhier(self.testlogdir)
+self.logfile = os.path.join(self.testlogdir, "sdk_target_log.%s" % 
self.datetime)
+BuildProject.__init__(self, d, uri, foldername, tmpdir=testpath)
+
+def download_archive(self):
+
+self._download_archive()
+
+cmd = 'tar xf %s%s -C %s' % (self.targetdir, self.archive, 
self.targetdir)
+subprocess.check_call(cmd, shell=True)
+
+#Change targetdir to project folder
+self.targetdir = self.targetdir + self.fname
+
+def run_configure(self, configure_args=''):
+return super(SDKBuildProject, 
self).run_configure(configure_args=(configure_args or '$CONFIGURE_FLAGS'))
+
+def run_install(self, install_args=''):
+return super(SDKBuildProject, 
self).run_install(install_args=(install_args or "DESTDIR=%s/../install" % 
self.targetdir))
+
+def log(self, msg):
+if sel

[OE-core] [PATCH 2/4] oeqa/oetest.py: enable sdk testing

[Corneliu Stoicescu]

- add support for sdk tests in the loadTests and runTests methods
- add new oeSDKTest test object

NOTE: Original patch made by: Richard Purdie 


Signed-off-by: Corneliu Stoicescu 
---
 meta/lib/oeqa/oetest.py | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index dcbd498..5552c43 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -10,25 +10,29 @@
 import os, re, mmap
 import unittest
 import inspect
+import subprocess
 from oeqa.utils.decorators import LogResults
 
-def loadTests(tc):
-
-# set the context object passed from the test class
-setattr(oeTest, "tc", tc)
-# set ps command to use
-setattr(oeRuntimeTest, "pscmd", "ps -ef" if oeTest.hasPackage("procps") 
else "ps")
-# prepare test suite, loader and runner
-suite = unittest.TestSuite()
+def loadTests(tc, type="runtime"):
+if type == "runtime":
+# set the context object passed from the test class
+setattr(oeTest, "tc", tc)
+# set ps command to use
+setattr(oeRuntimeTest, "pscmd", "ps -ef" if 
oeTest.hasPackage("procps") else "ps")
+# prepare test suite, loader and runner
+suite = unittest.TestSuite()
+elif type == "sdk":
+# set the context object passed from the test class
+setattr(oeSDKTest, "tc", tc)
 testloader = unittest.TestLoader()
 testloader.sortTestMethodsUsing = None
 suite = testloader.loadTestsFromNames(tc.testslist)
 
 return suite
 
-def runTests(tc):
+def runTests(tc, type="runtime"):
 
-suite = loadTests(tc)
+suite = loadTests(tc, type)
 print("Test modules  %s" % tc.testslist)
 print("Found %s tests" % suite.countTestCases())
 runner = unittest.TextTestRunner(verbosity=2)
@@ -58,11 +62,14 @@ class oeTest(unittest.TestCase):
 return False
 
 class oeRuntimeTest(oeTest):
-
 def __init__(self, methodName='runTest'):
 self.target = oeRuntimeTest.tc.target
 super(oeRuntimeTest, self).__init__(methodName)
 
+class oeSDKTest(unittest.TestCase):
+def __init__(self, methodName='runTest'):
+self.sdktestdir = oeSDKTest.tc.sdktestdir
+super(oeSDKTest, self).__init__(methodName)
 
 def getmodule(pos=2):
 # stack returns a list of tuples containg frame information
-- 
1.8.3.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/4] oeqa/sdk/: add sdk tests for sudoku, iptables and cvs

[Corneliu Stoicescu]

Add test modules for sdk tests.

NOTE: Original patch made by: Richard Purdie 


Signed-off-by: Corneliu Stoicescu 
---
 meta/lib/oeqa/sdk/__init__.py  |  3 +++
 meta/lib/oeqa/sdk/buildcvs.py  | 25 +
 meta/lib/oeqa/sdk/buildiptables.py | 26 ++
 meta/lib/oeqa/sdk/buildsudoku.py   | 22 ++
 4 files changed, 76 insertions(+)
 create mode 100644 meta/lib/oeqa/sdk/__init__.py
 create mode 100644 meta/lib/oeqa/sdk/buildcvs.py
 create mode 100644 meta/lib/oeqa/sdk/buildiptables.py
 create mode 100644 meta/lib/oeqa/sdk/buildsudoku.py

diff --git a/meta/lib/oeqa/sdk/__init__.py b/meta/lib/oeqa/sdk/__init__.py
new file mode 100644
index 000..4cf3fa7
--- /dev/null
+++ b/meta/lib/oeqa/sdk/__init__.py
@@ -0,0 +1,3 @@
+# Enable other layers to have tests in the same named directory
+from pkgutil import extend_path
+__path__ = extend_path(__path__, __name__)
diff --git a/meta/lib/oeqa/sdk/buildcvs.py b/meta/lib/oeqa/sdk/buildcvs.py
new file mode 100644
index 000..c7146fa
--- /dev/null
+++ b/meta/lib/oeqa/sdk/buildcvs.py
@@ -0,0 +1,25 @@
+from oeqa.oetest import oeSDKTest, skipModule
+from oeqa.utils.decorators import *
+from oeqa.utils.targetbuild import SDKBuildProject
+
+class BuildCvsTest(oeSDKTest):
+
+@classmethod
+def setUpClass(self):
+self.project = SDKBuildProject(oeSDKTest.tc.sdktestdir + "/cvs/", 
oeSDKTest.tc.sdkenv, oeSDKTest.tc.d,
+
"http://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.13/cvs-1.12.13.tar.bz2";)
+self.project.download_archive()
+
+def test_cvs(self):
+self.assertEqual(self.project.run_configure(), 0,
+msg="Running configure failed")
+
+self.assertEqual(self.project.run_make(), 0,
+msg="Running make failed")
+
+self.assertEqual(self.project.run_install(), 0,
+msg="Running make install failed")
+
+@classmethod
+def tearDownClass(self):
+self.project.clean()
diff --git a/meta/lib/oeqa/sdk/buildiptables.py 
b/meta/lib/oeqa/sdk/buildiptables.py
new file mode 100644
index 000..062e531
--- /dev/null
+++ b/meta/lib/oeqa/sdk/buildiptables.py
@@ -0,0 +1,26 @@
+from oeqa.oetest import oeSDKTest
+from oeqa.utils.decorators import *
+from oeqa.utils.targetbuild import SDKBuildProject
+
+
+class BuildIptablesTest(oeSDKTest):
+
+@classmethod
+def setUpClass(self):
+self.project = SDKBuildProject(oeSDKTest.tc.sdktestdir + "/iptables/", 
oeSDKTest.tc.sdkenv, oeSDKTest.tc.d,
+
"http://netfilter.org/projects/iptables/files/iptables-1.4.13.tar.bz2";)
+self.project.download_archive()
+
+def test_iptables(self):
+self.assertEqual(self.project.run_configure(), 0,
+msg="Running configure failed")
+
+self.assertEqual(self.project.run_make(), 0,
+msg="Running make failed")
+
+self.assertEqual(self.project.run_install(), 0,
+msg="Running make install failed")
+
+@classmethod
+def tearDownClass(self):
+self.project.clean()
diff --git a/meta/lib/oeqa/sdk/buildsudoku.py b/meta/lib/oeqa/sdk/buildsudoku.py
new file mode 100644
index 000..6a60c76
--- /dev/null
+++ b/meta/lib/oeqa/sdk/buildsudoku.py
@@ -0,0 +1,22 @@
+from oeqa.oetest import oeSDKTest, skipModule
+from oeqa.utils.decorators import *
+from oeqa.utils.targetbuild import SDKBuildProject
+
+class SudokuTest(oeSDKTest):
+
+@classmethod
+def setUpClass(self):
+self.project = SDKBuildProject(oeSDKTest.tc.sdktestdir + "/sudoku/", 
oeSDKTest.tc.sdkenv, oeSDKTest.tc.d,
+
"http://downloads.sourceforge.net/project/sudoku-savant/sudoku-savant/sudoku-savant-1.3/sudoku-savant-1.3.tar.bz2";)
+self.project.download_archive()
+
+def test_sudoku(self):
+self.assertEqual(self.project.run_configure(), 0,
+msg="Running configure failed")
+
+self.assertEqual(self.project.run_make(), 0,
+msg="Running make failed")
+
+@classmethod
+def tearDownClass(self):
+self.project.clean()
-- 
1.8.3.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/4] Enable automated sdk tests

[Corneliu Stoicescu]

This series of patches contain the changes and additions needed to enable 
automated sdk tests. They are handeled similar to the automated runtime tests, 
sharing both code and test files.

The original version of these patches was created by Richard Purdie 
.

However, I did not manage to sort out all the isses, and here they are:
- no setUpModule is used in the sdk test modules. This mean these tests will 
run for every sdk test run(not really an issue, as long as the tests are 
configured well)
- I left out the testsdk_auto task (should wotk similar to testimage_auto) 
because I did not get it to work properly. Please note that, for some reason, 
testimage_auto is also faulty. I will open a bug for this.

Here is the TODO list for this:
- add a cache system for package downloading (using /tmp to download packages 
for testing means we have to re-download them every time)
- investigate: unify the files/ directory for all tests (now we have a specific 
runtime/files/ directory for example)


Corneliu Stoicescu (4):
  meta/classes/testimage.bbclass: add testsdk task and enable
functionality for it.
  oeqa/oetest.py: enable sdk testing
  oeqa/utils/targetbuild.py: add support for sdk tests
  oeqa/sdk/: add sdk tests for sudoku, iptables and cvs

 meta/classes/testimage.bbclass | 97 +++---
 meta/lib/oeqa/oetest.py| 29 +++-
 meta/lib/oeqa/sdk/__init__.py  |  3 ++
 meta/lib/oeqa/sdk/buildcvs.py  | 25 ++
 meta/lib/oeqa/sdk/buildiptables.py | 26 ++
 meta/lib/oeqa/sdk/buildsudoku.py   | 22 +
 meta/lib/oeqa/utils/targetbuild.py | 94 ++--
 7 files changed, 263 insertions(+), 33 deletions(-)
 create mode 100644 meta/lib/oeqa/sdk/__init__.py
 create mode 100644 meta/lib/oeqa/sdk/buildcvs.py
 create mode 100644 meta/lib/oeqa/sdk/buildiptables.py
 create mode 100644 meta/lib/oeqa/sdk/buildsudoku.py

-- 
1.8.3.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/4] meta/classes/testimage.bbclass: add testsdk task and enable functionality for it.

[Corneliu Stoicescu]

- add new testsdk task for meta-toolchain testing.
- enable the get_tests_list method to work with sdk tests.
- add default TEST_SUITES value for meta-toolchain package

NOTE: Original patch made by: Richard Purdie 


Signed-off-by: Corneliu Stoicescu 
---
 meta/classes/testimage.bbclass | 97 +++---
 1 file changed, 90 insertions(+), 7 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 285c6a9..97d0380 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -19,7 +19,7 @@
 # Note that order in TEST_SUITES is important (it's the order tests run) and 
it influences tests dependencies.
 # A layer can add its own tests in lib/oeqa/runtime, provided it extends 
BBPATH as normal in its layer.conf.
 
-# TEST_LOG_DIR contains a ssh log (what command is running, output and return 
codes) and a qemu boot log till login
+# TEST_LOG_DIR contains a command ssh log and may contain infromation about 
what command is running, output and return codes and for qemu a boot log till 
login.
 # Booting is handled by this class, and it's not a test in itself.
 # TEST_QEMUBOOT_TIMEOUT can be used to set the maximum time in seconds the 
launch code will wait for the login prompt.
 
@@ -32,6 +32,7 @@ DEFAULT_TEST_SUITES = "ping auto"
 DEFAULT_TEST_SUITES_pn-core-image-minimal = "ping"
 DEFAULT_TEST_SUITES_pn-core-image-sato = "ping ssh df connman syslog xorg scp 
vnc date rpm smart dmesg python"
 DEFAULT_TEST_SUITES_pn-core-image-sato-sdk = "ping ssh df connman syslog xorg 
scp vnc date perl ldd gcc rpm smart kernelmodule dmesg python"
+DEFAULT_TEST_SUITES_pn-meta-toolchain = "auto"
 TEST_SUITES ?= "${DEFAULT_TEST_SUITES}"
 
 TEST_QEMUBOOT_TIMEOUT ?= "1000"
@@ -53,8 +54,15 @@ do_testimage[nostamp] = "1"
 do_testimage[depends] += "${TESTIMAGEDEPENDS}"
 do_testimage[lockfiles] += "${TESTIMAGELOCK}"
 
+python do_testsdk() {
+testsdk_main(d)
+}
+addtask testsdk
+do_testsdk[nostamp] = "1"
+do_testsdk[depends] += "${TESTIMAGEDEPENDS}"
+do_testsdk[lockfiles] += "${TESTIMAGELOCK}"
 
-def get_tests_list(d):
+def get_tests_list(d, type="runtime"):
 testsuites = d.getVar("TEST_SUITES", True).split()
 bbpath = d.getVar("BBPATH", True).split(':')
 
@@ -65,12 +73,12 @@ def get_tests_list(d):
 if testname != "auto":
 found = False
 for p in bbpath:
-if os.path.exists(os.path.join(p, 'lib', 'oeqa', 'runtime', 
testname + '.py')):
-testslist.append("oeqa.runtime." + testname)
+if os.path.exists(os.path.join(p, 'lib', 'oeqa', type, 
testname + '.py')):
+testslist.append("oeqa." + type + "." + testname)
 found = True
 break
 if not found:
-bb.error('Test %s specified in TEST_SUITES could not be found 
in lib/oeqa/runtime under BBPATH' % testname)
+bb.fatal('Test %s specified in TEST_SUITES could not be found 
in lib/oeqa/runtime under BBPATH' % testname)
 
 if "auto" in testsuites:
 def add_auto_list(path):
@@ -78,12 +86,12 @@ def get_tests_list(d):
 bb.fatal('Tests directory %s exists but is missing 
__init__.py' % path)
 files = sorted([f for f in os.listdir(path) if f.endswith('.py') 
and not f.startswith('_')])
 for f in files:
-module = 'oeqa.runtime.' + f[:-3]
+module = 'oeqa.' + type + '.' + f[:-3]
 if module not in testslist:
 testslist.append(module)
 
 for p in bbpath:
-testpath = os.path.join(p, 'lib', 'oeqa', 'runtime')
+testpath = os.path.join(p, 'lib', 'oeqa', type)
 bb.debug(2, 'Searching for tests in %s' % testpath)
 if os.path.exists(testpath):
 add_auto_list(testpath)
@@ -230,3 +238,78 @@ def testimage_main(d):
 target.stop()
 
 testimage_main[vardepsexclude] =+ "BB_ORIGENV"
+
+
+def testsdk_main(d):
+import unittest
+import os
+import glob
+import oeqa.runtime
+import oeqa.sdk
+import time
+import subprocess
+from oeqa.oetest import loadTests, runTests
+
+pn = d.getVar("PN", True)
+bb.utils.mkdirhier(d.getVar("TEST_LOG_DIR", True))
+
+# tests in TEST_SUITES become required tests
+# they won't be skipped even if they aren't suitable.
+# testslist is what we'll actually pass to the unittest loader
+testslist = get_tests_list(d, "sdk")
+testsrequired = [t for t in d.getVar("TEST_SUITES", True).split() if t != 
"auto"]
+
+sdktestdir = d.expand("${WORKDIR}/testimage-sdk/")
+bb.utils.remove(sdktestdir, True)
+bb.utils.mkdirhier(sdktestdir)
+
+tcname = d.expand("${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh")
+if not os.path.exists(tcname):
+bb.fatal("The toolchain is not built. Build it before running the 
tests: 'bitbake meta-toolchain' .")
+subproces

[OE-core] [PATCH] oeqa/runtime: add new cpp test and file

[Corneliu Stoicescu]

Signed-off-by: Corneliu Stoicescu 
Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/runtime/files/test.cpp | 3 +++
 meta/lib/oeqa/runtime/gcc.py | 7 +++
 2 files changed, 10 insertions(+)
 create mode 100644 meta/lib/oeqa/runtime/files/test.cpp

diff --git a/meta/lib/oeqa/runtime/files/test.cpp 
b/meta/lib/oeqa/runtime/files/test.cpp
new file mode 100644
index 000..9e1a764
--- /dev/null
+++ b/meta/lib/oeqa/runtime/files/test.cpp
@@ -0,0 +1,3 @@
+#include 
+
+int main() {}
\ No newline at end of file
diff --git a/meta/lib/oeqa/runtime/gcc.py b/meta/lib/oeqa/runtime/gcc.py
index 08b3cf1..a7f62e1 100644
--- a/meta/lib/oeqa/runtime/gcc.py
+++ b/meta/lib/oeqa/runtime/gcc.py
@@ -14,6 +14,7 @@ class GccCompileTest(oeRuntimeTest):
 def setUpClass(self):
 
oeRuntimeTest.tc.target.copy_to(os.path.join(oeRuntimeTest.tc.filesdir, 
"test.c"), "/tmp/test.c")
 
oeRuntimeTest.tc.target.copy_to(os.path.join(oeRuntimeTest.tc.filesdir, 
"testmakefile"), "/tmp/testmakefile")
+
oeRuntimeTest.tc.target.copy_to(os.path.join(oeRuntimeTest.tc.filesdir, 
"test.cpp"), "/tmp/test.cpp")
 
 @testcase(203)
 def test_gcc_compile(self):
@@ -29,6 +30,12 @@ class GccCompileTest(oeRuntimeTest):
 (status, output) = self.target.run('/tmp/test')
 self.assertEqual(status, 0, msg="running compiled file failed, output 
%s" % output)
 
+def test_gpp2_compile(self):
+(status, output) = self.target.run('g++ /tmp/test.cpp -o /tmp/test 
-lm')
+self.assertEqual(status, 0, msg="g++ compile failed, output: %s" % 
output)
+(status, output) = self.target.run('/tmp/test')
+self.assertEqual(status, 0, msg="running compiled file failed, output 
%s" % output)
+
 @testcase(204)
 def test_make(self):
 (status, output) = self.target.run('cd /tmp; make -f testmakefile')
-- 
1.8.3.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] State of bitbake world, test-dependencies 2014-08-08

[Martin Jansa]

On Fri, Jul 25, 2014 at 05:40:21PM +0200, Martin Jansa wrote:
> Complete logs:
> http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20140724_145905.log/
> 
> ERROR: 46 issues were found in these recipes: gst-ffmpeg lttng-modules 
> modemmanager monkey openal-soft ...

I've sent fixes for gst-ffmpeg, openal-soft, qttools, qtimageformats

I'll look into few more, because it's annoying how long they are in this list.
I don't use any of these so I'll look into them in order of number of issues
they have (tracker will be first). I'll also care less about fixing it 
"properly"
with PACKAGECONFIGs and will just throw all DEPENDS in (people using these
recipes had enough time to fix it properly and it can be converted to 
PACKAGECONFIG
later).

Complete logs:
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20140808_063907.log/

ERROR: 483 issues were found in these recipes: directfb engrave epiphany 
expedite gd gmtk gnome-disk-utility gst-ffmpeg guile leptonica libarchive 
libmicrohttpd libmikmod libungif libwebp libwmf mariadb midori mpd mpeg2dec 
mpg123 openal-soft opendataplane oscam piglit protobuf snort sox stunnel 
synergy tesseract tracker

This is first report with the message format unified with insane_qa check.

WARN: directfb: directfb rdepends on eglibc but it's not a build dependency?
WARN: directfb: directfb rdepends on freetype but it's not a build dependency?
WARN: directfb: directfb rdepends on libdrm but it's not a build dependency?
WARN: directfb: directfb rdepends on libdrm-kms but it's not a build dependency?
WARN: directfb: directfb rdepends on libgcc but it's not a build dependency?
WARN: directfb: directfb rdepends on libjpeg-turbo but it's not a build 
dependency?
WARN: directfb: directfb rdepends on liblzma but it's not a build dependency?
WARN: directfb: directfb rdepends on libpng but it's not a build dependency?
WARN: directfb: directfb rdepends on libstdc++ but it's not a build dependency?
WARN: directfb: directfb rdepends on libwebp but it's not a build dependency?
WARN: directfb: directfb rdepends on tiff but it's not a build dependency?
WARN: directfb: directfb rdepends on tslib but it's not a build dependency?
WARN: directfb: directfb rdepends on zlib but it's not a build dependency?
WARN: engrave: engrave rdepends on ecore but it's not a build dependency?
WARN: engrave: engrave rdepends on ecore-evas but it's not a build dependency?
WARN: engrave: engrave rdepends on ecore-input but it's not a build dependency?
WARN: engrave: engrave rdepends on ecore-input-evas but it's not a build 
dependency?
WARN: engrave: engrave rdepends on eglibc but it's not a build dependency?
WARN: engrave: engrave rdepends on eina but it's not a build dependency?
WARN: engrave: engrave rdepends on eo but it's not a build dependency?
WARN: engrave: engrave rdepends on evas but it's not a build dependency?
WARN: engrave: engrave rdepends on expat but it's not a build dependency?
WARN: engrave: engrave rdepends on flex but it's not a build dependency?
WARN: engrave: engrave rdepends on fontconfig but it's not a build dependency?
WARN: engrave: engrave rdepends on freetype but it's not a build dependency?
WARN: engrave: engrave rdepends on fribidi but it's not a build dependency?
WARN: engrave: engrave rdepends on glib-2.0 but it's not a build dependency?
WARN: engrave: engrave rdepends on libcrypto but it's not a build dependency?
WARN: engrave: engrave rdepends on libeet but it's not a build dependency?
WARN: engrave: engrave rdepends on libjpeg-turbo but it's not a build 
dependency?
WARN: engrave: engrave rdepends on libpng but it's not a build dependency?
WARN: engrave: engrave rdepends on libssl but it's not a build dependency?
WARN: engrave: engrave rdepends on libstdc++ but it's not a build dependency?
WARN: engrave: engrave rdepends on luajit but it's not a build dependency?
WARN: engrave: engrave rdepends on zlib but it's not a build dependency?
WARN: epiphany: epiphany rdepends on cairo but it's not a build dependency?
WARN: epiphany: epiphany rdepends on dbus-glib but it's not a build dependency?
WARN: epiphany: epiphany rdepends on dbus-lib but it's not a build dependency?
WARN: epiphany: epiphany rdepends on eglibc but it's not a build dependency?
WARN: epiphany: epiphany rdepends on gconf but it's not a build dependency?
WARN: epiphany: epiphany rdepends on gdk-pixbuf but it's not a build dependency?
WARN: epiphany: epiphany rdepends on glib-2.0 but it's not a build dependency?
WARN: epiphany: epiphany rdepends on gtk+ but it's not a build dependency?
WARN: epiphany: epiphany rdepends on hicolor-icon-theme but it's not a build 
dependency?
WARN: epiphany: epiphany rdepends on iso-codes but it's not a build dependency?
WARN: epiphany: epiphany rdepends on libavahi-client but it's not a build 
dependency?
WARN: epiphany: epiphany rdepends on libavahi-common but it's not a build 
dependency?
WARN: epiphany: epiphany rdepends on libavahi-gobject but it's not a build

[OE-core] [dora][backport][PATCH] kernel: don't copy .so.dbg files into kernel source install

[Koen Kooi]

From: Bruce Ashfield 

In 3.16+ x86-64 kernel builds produce a vdso64.so.dbg file. If this file is
copied into the kernel source install multiple QA failures are triggered.
Specifically, this file triggers a debug package split that results in
files installed but not shipped, and invalid .debug file errors.

By ensuring that .so files are not copied, we avoid this incorrect split
with no impact on future build phases.

Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b2e9d4c..1289873 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -232,7 +232,7 @@ kernel_do_install() {
# dir. This ensures the original Makefiles are used and not the
# redirecting Makefiles in the build directory.
#
-   find . -depth -not -name "*.cmd" -not -name "*.o" -not -path 
"./Documentation*" -not -path "./source*" -not -path "./.*" -print0 | cpio 
--null -pdlu $kerneldir
+   find . -depth -not -name "*.cmd" -not -name "*.o" -not -name "*.so.dbg" 
-not -path "./Documentation*" -not -path "./source*" -not -path "./.*" -print0 
| cpio --null -pdlu $kerneldir
cp .config $kerneldir
if [ "${S}" != "${B}" ]; then
pwd="$PWD"
-- 
1.9.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] nssmyhostname: fix runtime dependencies

[Martin Jansa]

On Sat, Aug 09, 2014 at 10:26:49AM +0200, Koen Kooi wrote:
> This should fix:
> 
> 19:40  ERROR: Unable to install packages. Command 
> '/mnt/ci_build/workspace/tmp/sysroots/x86_64-linux/usr/bin/opkg-cl -f 
> /mnt/ci_build/workspace/tmp/work/genericarmv8-oe-linux/linaro-image-minimal/1.0-r0/opkg.conf
>  -o
>  
> /mnt/ci_build/workspace/tmp/work/genericarmv8-oe-linux/linaro-image-minimal/1.0-r0/rootfs
>  --force_postinstall --prefer-arch-to-version   install opkg-collateral 
> stress libnss-myhostname2 run-postinsts auto-serial-console
>  util-linux-fsck stress-dbg packagegroup-co
> 19:41  sed: can't read 
> /mnt/ci_build/workspace/tmp/work/aarch64-oe-linux/nss-myhostname/0.3-r0/image/etc/nsswitch.conf:
>  No such file or directory

Can you please check which recipe is supposed to install
libnss_myhostname.so.2 and kill it in the other one?

WARNING: The recipe systemd is trying to install files into a shared
area when those files already exist. Those files and their manifest
location are:
   
/home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libnss_myhostname.so.2
   Matched in manifest-qemux86-64-nss-myhostname.populate_sysroot

> Signed-off-by: Koen Kooi 
> ---
>  meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb 
> b/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
> index d8ec863..b9ddeaf 100644
> --- a/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
> +++ b/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
> @@ -13,6 +13,9 @@ SRC_URI[sha256sum] = 
> "2ba744ea8d578d1c57c85884e94a3042ee17843a5294434d3a7f6c4d67
>  
>  inherit autotools
>  
> +# /etc/nsswitch.conf needs to be present
> +RDEPENDS_${PN} = "base-files"
> +
>  pkg_postinst_${PN} () {
>   sed -e '/^hosts:/s/\s*\//' \
>   -e 's/\(^hosts:.*\)\(\\)\(.*\)\(\\)\(.*\)/\1\2 
> myhostname \3\4\5/' \
> -- 
> 1.9.3
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] RFC: Improving the developer workflow

[Mike Looijmans]

On 08/09/2014 10:44 AM, Alex J Lennon wrote:


On 09/08/2014 09:13, Mike Looijmans wrote:

On 08/07/2014 03:05 PM, Paul Eggleton wrote:

On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:

Historically I, and I suspect others, have done full image updates of
the storage medium,  onboard flash or whatever but these images are
getting so big now that I am trying to  move away from that and into
using package feeds for updates to embedded targets.


Personally with how fragile package management can end up being, I'm
convinced
that full-image updates are the way to go for a lot of cases, but
ideally with
some intelligence so that you only ship the changes (at a filesystem
level
rather than a package or file level). This ensures that an upgraded
image on
one device ends up exactly identical to any other device including a
newly
deployed one. Of course it does assume that you have a read-only
rootfs and
keep your configuration data / logs / other writeable data on a separate
partition or storage medium. However, beyond improvements to support for
having a read-only rootfs we haven't really achieved anything in
terms of out-
of-the-box support for this, mainly due to lack of resources.


Full-image upgrades are probably most seen in "lab" environments,
where the software is being developed.

Once deployed to customers, who will not be using a build system, the
system must rely on packages and online updates.

Embedded systems look more like desktops these days.

- End-users will make changes to the system:
- "plugins" and other applications.
- configuration data
- application data (e.g. loggings, EPG data)
- There is not enough room in the flash for two full images.
- There is usually a virtually indestructable bootloader that can
recover even from fully erasing the NAND flash.
- Flash filesystems are usually NAND. NAND isn't suitable for
read-only root filesystems, you want to wear-level across the whole
flash.



Agreeing with much you say Mike, I was under the impression that there
are block management layers now which will wear level across partitions?

So you could have your read only partition but still wear levelled
across the NAND ?


Going off-topic here I guess, but I think you can use the UBI block 
layer in combination with e.g. squashfs. Never tried it, but it should 
be possible to create an UBI volume, write a squash blob into it and 
mount that.


However, any system that accomplishes that, is sort of cheating. It 
isn't a read-only rootfs in the true meaning of the word any more. In 
time, the volume will move around on the flash, thus the rootfs will be 
re-written.



For the OpenPLi settop boxes we've been using "online upgrades" which
basically just call "opkg update && opkg upgrade" for many years, and
there's never been a real disaster. The benefits easily outweigh the
drawbacks.

When considering system upgrades, too much attention is being spent in
the "corner cases". It's not really a problem if the box is bricked
when the power fails during an upgrade. As long as there's a procedure
the end-user can use to recover the system (on most settop boxes,
debricking the system is just a matter of inserting a USB stick and
flipping the power switch).


For us on this latest project - and indeed the past few projects - it is
a major problem (and cost) if the device is bricked. These devices are
not user-maintainable and we'd be sending engineers out around the world
to fix.

Not a good impression to make with the customers either.

Whether we're a usual use case I don't know.


I think you're a very usual use case, and it's a valid one indeed. I'm 
just trying to create awareness that there are projects out there that 
use OE for consumer products, and have millions of devices running in 
the end-users' living rooms, who upgrade at a whim (feed servers sending 
out about 4TB traffic each month).


I've also done medical devices where, just as you say, bricking it just 
isn't an option. These are typically inaccessible by the end-user, and 
see no modification other than about 1k of configuration data (e.g. wifi 
keys) during their lifespan.


--
Mike Looijmans
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] nssmyhostname: fix runtime dependencies

[Koen Kooi]

Op 9 aug. 2014, om 12:34 heeft Martin Jansa  het 
volgende geschreven:

> On Sat, Aug 09, 2014 at 10:26:49AM +0200, Koen Kooi wrote:
>> This should fix:
>> 
>> 19:40  ERROR: Unable to install packages. Command 
>> '/mnt/ci_build/workspace/tmp/sysroots/x86_64-linux/usr/bin/opkg-cl -f 
>> /mnt/ci_build/workspace/tmp/work/genericarmv8-oe-linux/linaro-image-minimal/1.0-r0/opkg.conf
>>  -o
>> 
>> /mnt/ci_build/workspace/tmp/work/genericarmv8-oe-linux/linaro-image-minimal/1.0-r0/rootfs
>>  --force_postinstall --prefer-arch-to-version   install opkg-collateral 
>> stress libnss-myhostname2 run-postinsts auto-serial-console
>> util-linux-fsck stress-dbg packagegroup-co
>> 19:41  sed: can't read 
>> /mnt/ci_build/workspace/tmp/work/aarch64-oe-linux/nss-myhostname/0.3-r0/image/etc/nsswitch.conf:
>>  No such file or directory
> 
> Can you please check which recipe is supposed to install
> libnss_myhostname.so.2 and kill it in the other one?
> 
> WARNING: The recipe systemd is trying to install files into a shared
> area when those files already exist. Those files and their manifest
> location are:
>   
> /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libnss_myhostname.so.2
>   Matched in manifest-qemux86-64-nss-myhostname.populate_sysroot

That's what http://patches.openembedded.org/patch/77643/ is for, but I'm not 
sure how to properly fix this, since not everyone has systemd in 
DISTRO_FEATURES.
Either way systemd needs to have postinst/postrm scripts for myhostname as 
well. Hopefully I'll have some time next week at work for this.

regards,

Koen

> 
>> Signed-off-by: Koen Kooi 
>> ---
>> meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb 
>> b/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
>> index d8ec863..b9ddeaf 100644
>> --- a/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
>> +++ b/meta/recipes-support/nss-myhostname/nss-myhostname_0.3.bb
>> @@ -13,6 +13,9 @@ SRC_URI[sha256sum] = 
>> "2ba744ea8d578d1c57c85884e94a3042ee17843a5294434d3a7f6c4d67
>> 
>> inherit autotools
>> 
>> +# /etc/nsswitch.conf needs to be present
>> +RDEPENDS_${PN} = "base-files"
>> +
>> pkg_postinst_${PN} () {
>>  sed -e '/^hosts:/s/\s*\//' \
>>  -e 's/\(^hosts:.*\)\(\\)\(.*\)\(\\)\(.*\)/\1\2 
>> myhostname \3\4\5/' \
>> -- 
>> 1.9.3
>> 
>> -- 
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tslib: Delete unnecessary "SRC_URI_OVERRIDES_PACKAGE_ARCH = 0"

[Robert P. J. Day]

Since the machine-specific files for tslib were removed quite some
time ago, there is no need for this directive anymore.

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

---

diff --git a/meta/recipes-graphics/tslib/tslib_1.1.bb 
b/meta/recipes-graphics/tslib/tslib_1.1.bb
index 05d58b6..6d8c7dd 100644
--- a/meta/recipes-graphics/tslib/tslib_1.1.bb
+++ b/meta/recipes-graphics/tslib/tslib_1.1.bb
@@ -32,8 +32,6 @@ do_install_append() {
install -m 0755 ${WORKDIR}/tslib.sh ${D}${sysconfdir}/profile.d/
 }

-SRC_URI_OVERRIDES_PACKAGE_ARCH = "0"
-
 # People should consider using udev's /dev/input/touchscreen0 symlink
 # instead of detect-stylus
 #RDEPENDS_tslib-conf_weird-machine = "detect-stylus"

-- 


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

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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] RFC: Improving the developer workflow

[Alex J Lennon]

On 09/08/2014 12:22, Mike Looijmans wrote:
> On 08/09/2014 10:44 AM, Alex J Lennon wrote:
>
> Going off-topic here I guess, but I think you can use the UBI block
> layer in combination with e.g. squashfs. Never tried it, but it should
> be possible to create an UBI volume, write a squash blob into it and
> mount that.
>
> However, any system that accomplishes that, is sort of cheating. It
> isn't a read-only rootfs in the true meaning of the word any more. In
> time, the volume will move around on the flash, thus the rootfs will
> be re-written.
>

I guess it comes down to what risks we're trying to guard against here?

Thinking aloud...

If I believe that my UBI - or other - layer is robust (and I think it is
nowadays?) then I should be able to believe that UBI can wear level my
data across NAND without a risk of data-loss due to bad sectors, power
interruption or other (assuming enough spare blocks)

Now if that's a true statement then the risk of my main
'read-only-but-wear-levelled' file-system becoming corrupted due to this
is very low.

I think I would accept that risk - with some testing to prove it out to
myself - given that the main file-system partition is likely to be the
largest partition and if I am minimising cost/size of flash then I want
to be able to wear level using that larger area.

I've had exactly this problem before with e.g. data/logs on small
read-write data partitions which rapidly kill the flash as there's a
very small area being wear levelled.


So, what I am thinking is more of a risk for us is if I remount that OS
filesystem as read/write and start doing some kind of update to it,
whether via package feeds or some delta-based system?

I think if I could remount read-write / start a transaction / do the
update / commit the update transaction that would be rather good. And of
course if it gets interrupted or otherwise fails we just roll-back.

>>> For the OpenPLi settop boxes we've been using "online upgrades" which
>>> basically just call "opkg update && opkg upgrade" for many years, and
>>> there's never been a real disaster. The benefits easily outweigh the
>>> drawbacks.
>>>
>>> When considering system upgrades, too much attention is being spent in
>>> the "corner cases". It's not really a problem if the box is bricked
>>> when the power fails during an upgrade. As long as there's a procedure
>>> the end-user can use to recover the system (on most settop boxes,
>>> debricking the system is just a matter of inserting a USB stick and
>>> flipping the power switch).
>>
>> For us on this latest project - and indeed the past few projects - it is
>> a major problem (and cost) if the device is bricked. These devices are
>> not user-maintainable and we'd be sending engineers out around the world
>> to fix.
>>
>> Not a good impression to make with the customers either.
>>
>> Whether we're a usual use case I don't know.
>
> I think you're a very usual use case, and it's a valid one indeed. I'm
> just trying to create awareness that there are projects out there that
> use OE for consumer products, and have millions of devices running in
> the end-users' living rooms, who upgrade at a whim (feed servers
> sending out about 4TB traffic each month).
>
> I've also done medical devices where, just as you say, bricking it
> just isn't an option. These are typically inaccessible by the
> end-user, and see no modification other than about 1k of configuration
> data (e.g. wifi keys) during their lifespan.
>

That's really interesting. Do you mind me asking who pays for that
traffic? (!)

Yes we have done some medical devices in the past. This current crop is
smart buildings which is similarly difficult to access if something
blows up.
Then we've done some in-car telematics and train telemetry which is all
similarly difficult due to inaccessibility, maintenance constraints, and the
desire to keep the users' fingers out of the device.

I guess it's horses for courses isn't it. Glad to hear I'm not too much
of an outlier ;)

Cheers,

Alex

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] How to force patch application

[Giuseppe Condorelli]

Many thanks Steve, I'll test it when possible. 
Enjoy your time. 
Giuseppe

> Il giorno 08/ago/2014, alle ore 00:25, Stephen Arnold 
>  ha scritto:
> 
> Yes, what I said previously:
> 
> 1) disable current patch: add ";patch=0" to the end of the patch line in 
> SRC_URI
> 2a) add your patch to SRC_URI (if different than patch above)
> 2b) make your own do_patch() to apply the patch
> 2c) try this example for a way to supplement do_patch with your own function:
> meta-openembedded/meta-networking/recipes-support/netcat/netcat-openbsd_1.105.bb
> 3) test it
> 
> Steve
> 
> 
>> On Thu, Aug 7, 2014 at 7:51 AM, Giuseppe Condorelli 
>>  wrote:
>> Hi Steve,
>>  
>> thanks for the reply.
>>  
>> The problem is that I need to force a patch application (like patch --force 
>> option) at my own risk.
>> Do you see any solution?
>> Giuseppe
>> 
>> 
>> 2014-08-07 16:43 GMT+02:00 Stephen Arnold :
>> 
>>> Not sure if there's an easy way with quilt (check the quilt options) but a 
>>> relatively easy way would be to use your own patch routine (essentially 
>>> anything you want).  One thing you could do is disable the normal patch 
>>> application (add ";patch=0" to the end of the patch line in SRC_URI) and 
>>> then use your own do_patch to force it (if that's really what you want to 
>>> do).  I guess I would ask "why?" and if it were me I'd just reroll the 
>>> patch and fix it.  But I don't know what the real problem is, so...
>>> 
>>> Steve
>>> 
>>> 
>>> 
 On Thu, Aug 7, 2014 at 6:14 AM, Giuseppe Condorelli 
  wrote:
 Hi All,
  
 please can I know if is it possible, using the do_patch routine,
 to force the application of a given patch?
 I mean, like the patch --force command.
  
 Please let me know, I tried w/o good result.
  
 Best Regards,
 Giuseppe
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>> 
>>> 
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Error: package not found in the base feeds

[Himanshu Pandey]

Hi,I am getting following error:Error: spread not found in the base feeds 
(genericx86_64 x86_64 noarch any all).Error: liburiparser not found in the base 
feeds (genericx86_64 x86_64 noarch any all).

Please help to resolve the same.
Regards,Himanshu-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Remove "SRC_URI_OVERRIDES_PACKAGE_ARCH = 0" from tslib.bb

[Robert P. J. Day]

On Fri, 8 Aug 2014, Saul Wold wrote:

> On 08/08/2014 12:31 PM, Robert P. J. Day wrote:
> >
> > Given that there are no machine-specific files for the tslib recipe
> > anymore, might as well remove this line.
> >
>
> Robert,
>
> Can you please review the commit guidelines
>
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
>
> The summary line should be in the form of
> tslib: Remove ...

  serious question -- how does one identify the "primary item" under
consideration if it's scattered over several files. recently, i
submitted a patch to remove a few references to "do_package_write",
a deleted task. the existing references under meta/:

conf/documentation.conf:do_package_write[doc] = "Creates the actual packages 
and places them in the Package Feed area"
recipes-core/meta/meta-ide-support.bb:do_populate_ide_support[recrdeptask] = 
"do_package_write"
recipes-core/meta/package-index.bb:do_package_write[noexec] = "1"
recipes-devtools/installer/adt-installer_1.0.bb:do_package_write[noexec] = "1"

  i'm assuming, in this case, the primary item would be
"do_package_write"?

rday

-- 


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

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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/8] mpeg2dec: add PACKAGECONFIG for x11 and fix dependencies

[Martin Jansa]

* the configure script checks for Xext and Xv when X/libvo is enabled
* fixes following warnings:
  WARN: mpeg2dec: mpeg2dec rdepends on libxext but it isn't a build dependency?
  WARN: mpeg2dec: mpeg2dec rdepends on libxv but it isn't a build dependency?

Signed-off-by: Martin Jansa 
---
 meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb 
b/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb
index 1211284..cede2bf 100644
--- a/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb
+++ b/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb
@@ -6,8 +6,6 @@ LICENSE_FLAGS = "commercial"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
file://include/mpeg2.h;beginline=1;endline=22;md5=ead62602d4638329d3b5b86a55803154"
 
-DEPENDS = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11', 
'', d)}"
-
 PR = "r2"
 
 SRC_URI = "http://libmpeg2.sourceforge.net/files/mpeg2dec-${PV}.tar.gz \
@@ -18,7 +16,10 @@ SRC_URI[sha256sum] = 
"c74a76068f8ec36d4bb59a03bf1157be44118ca02252180e8b358b0b5e
 
 inherit autotools pkgconfig
 
-EXTRA_OECONF = "--enable-shared --disable-sdl --with-x"
+EXTRA_OECONF = "--enable-shared --disable-sdl"
+
+PACKAGECONFIG ?= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', 
d)}"
+PACKAGECONFIG[x11] = "--with-x,--without-x,virtual/libx11 libxext libxv"
 
 PACKAGES = "mpeg2dec-dbg mpeg2dec mpeg2dec-doc libmpeg2 libmpeg2-dev 
libmpeg2convert libmpeg2convert-dev libmpeg2-staticdev 
libmpeg2convert-staticdev"
 
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 5/8] piglit: add dependency on libxrender

[Martin Jansa]

* fixes floating dependency:
  piglit/piglit/latest lost dependency on  libxrender

Signed-off-by: Martin Jansa 
---
 meta/recipes-graphics/piglit/piglit_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/piglit/piglit_git.bb 
b/meta/recipes-graphics/piglit/piglit_git.bb
index 64289ed..32e73af 100644
--- a/meta/recipes-graphics/piglit/piglit_git.bb
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -11,7 +11,7 @@ PV = "1.0+gitr${SRCPV}"
 
 S = "${WORKDIR}/git"
 
-DEPENDS = "virtual/libx11 waffle virtual/libgl libglu python-mako-native 
python-numpy-native"
+DEPENDS = "virtual/libx11 libxrender waffle virtual/libgl libglu 
python-mako-native python-numpy-native"
 
 # depends on virtual/libx11
 REQUIRED_DISTRO_FEATURES = "x11"
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/8] gst-fluendo*: add --disable-debug only to gst-fluendo-mp3

[Martin Jansa]

* fixes following QA warnings:
  gst-fluendo-mpegdemux-0.10.72: gst-fluendo-mpegdemux: configure was
passed unrecognised options: --disable-debug
[unknown-configure-option]

Signed-off-by: Martin Jansa 
---
 meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.19.bb | 3 +++
 meta/recipes-multimedia/gstreamer/gst-fluendo.inc| 3 +--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.19.bb 
b/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.19.bb
index 47dbc34..9e68288 100644
--- a/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.19.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.19.bb
@@ -5,6 +5,9 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=259a43dd1c9854b71fc396f74699f4d2"
 LICENSE_FLAGS = "commercial"
 
+GSTREAMER_DEBUG ?= "--disable-debug"
+EXTRA_OECONF += "${GSTREAMER_DEBUG}"
+
 acpaths = "-I ${S}/common/m4 -I ${S}/m4"
 
 SRC_URI[md5sum] = "5d95a9a216dd15bc5c00c9414061115c"
diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc 
b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
index c7e6595..feaf1c7 100644
--- a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
@@ -11,5 +11,4 @@ FILES_${PN} += "${libdir}/gstreamer-0.10/*.so"
 FILES_${PN}-dbg += "${libdir}/gstreamer-0.10/.debug"
 FILES_${PN}-dev += "${libdir}/gstreamer-0.10/*.la ${libdir}/gstreamer-0.10/*.a"
 
-GSTREAMER_DEBUG ?= "--disable-debug"
-EXTRA_OECONF = "${GSTREAMER_DEBUG} --disable-valgrind"
+EXTRA_OECONF = "--disable-valgrind"
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 6/8] midori: add dependency on libxscrnsaver

[Martin Jansa]

* fixes floating dependency:
  midori/midori/latest lost dependency on  libxscrnsaver

Signed-off-by: Martin Jansa 
---
 meta/recipes-sato/midori/midori_0.5.5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-sato/midori/midori_0.5.5.bb 
b/meta/recipes-sato/midori/midori_0.5.5.bb
index b359037..a9379e7 100644
--- a/meta/recipes-sato/midori/midori_0.5.5.bb
+++ b/meta/recipes-sato/midori/midori_0.5.5.bb
@@ -2,7 +2,7 @@ SUMMARY = "A lightweight web browser"
 HOMEPAGE = "http://www.twotoasts.de/index.php?/pages/midori_summary.html";
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=fbc093901857fcd118f065f900982c24"
-DEPENDS = "webkit-gtk libsoup-2.4 openssl python-native python-docutils-native 
librsvg-native libnotify libunique"
+DEPENDS = "webkit-gtk libsoup-2.4 openssl python-native python-docutils-native 
librsvg-native libnotify libunique libxscrnsaver"
 
 SRC_URI = "http://www.midori-browser.org/downloads/${BPN}_${PV}_all_.tar.bz2 \
 "
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 7/8] directfb: add PACKAGECONFIG for drmkms and tiff

[Martin Jansa]

* fixes following floating dependencies:
  directfb/directfb/latest lost dependency on  libdrm libdrm-kms liblzma tiff

Signed-off-by: Martin Jansa 
---
 meta/recipes-graphics/directfb/directfb.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/directfb/directfb.inc 
b/meta/recipes-graphics/directfb/directfb.inc
index 51dc09b..3dd0a5b 100644
--- a/meta/recipes-graphics/directfb/directfb.inc
+++ b/meta/recipes-graphics/directfb/directfb.inc
@@ -25,6 +25,8 @@ inherit autotools binconfig-disabled pkgconfig
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[jpeg2000] = "--enable-jpeg2000,--disable-jpeg2000,jasper"
+PACKAGECONFIG[drmkms] = "--enable-drmkms,--disable-drmkms,libdrm"
+PACKAGECONFIG[tiff] = "--enable-tiff,--disable-tiff,tiff"
 
 EXTRA_OECONF = "\
   --with-gfxdrivers=none \
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/8] test-dependencies, insane.bbclass: improve the message

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 meta/classes/insane.bbclass  | 2 +-
 scripts/test-dependencies.sh | 8 +---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 55bfaf2..3dd2e7f 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -794,7 +794,7 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, taskdeps, 
packages, d):
 break
 if rdep_data and 'PN' in rdep_data and rdep_data['PN'] in 
taskdeps:
 continue
-error_msg = "%s rdepends on %s but its not a build 
dependency?" % (pkg, rdepend)
+error_msg = "%s rdepends on %s, but it isn't a build 
dependency?" % (pkg, rdepend)
 sane = package_qa_handle_error("build-deps", error_msg, d)
 
 return sane
diff --git a/scripts/test-dependencies.sh b/scripts/test-dependencies.sh
index ecbb710..2bcc2ca 100755
--- a/scripts/test-dependencies.sh
+++ b/scripts/test-dependencies.sh
@@ -244,9 +244,11 @@ compare_deps() {
 else
   missing_deps=
   for dep in ${max_deps}; do
-echo "${min_deps}" | grep -q " ${dep} " || 
missing_deps="${missing_deps} ${dep}"
-echo # to get rid of dots on last line
-echo "WARN: ${recipe}: ${package} rdepends on ${dep} but its not a 
build dependency?" | tee -a ${OUTPUT_FILE}
+if ! echo "${min_deps}" | grep -q " ${dep} " ; then
+  missing_deps="${missing_deps} ${dep}"
+  echo # to get rid of dots on last line
+  echo "WARN: ${recipe}: ${package} rdepends on ${dep}, but it isn't a 
build dependency?" | tee -a ${OUTPUT_FILE}
+fi
   done
   if [ -n "${missing_deps}" ] ; then
 echo ${recipe} >> ${OUTPUTC}/failed-recipes.log
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 8/8] guile: add dependency on ncurses and readline

[Martin Jansa]

* fixes floating dependency:
  guile/guile/latest lost dependency on  ncurses-libncurses readline

Signed-off-by: Martin Jansa 
---
 meta/recipes-devtools/guile/guile_2.0.11.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/guile/guile_2.0.11.bb 
b/meta/recipes-devtools/guile/guile_2.0.11.bb
index d19460a..5b1e061 100644
--- a/meta/recipes-devtools/guile/guile_2.0.11.bb
+++ b/meta/recipes-devtools/guile/guile_2.0.11.bb
@@ -31,7 +31,7 @@ SRC_URI[sha256sum] = 
"aed0a4a6db4e310cbdfeb3613fa6f86fddc91ef624c1e3f8937a6304c6
 inherit autotools gettext pkgconfig texinfo
 BBCLASSEXTEND = "native"
 
-DEPENDS = "libunistring bdwgc gmp libtool libffi"
+DEPENDS = "libunistring bdwgc gmp libtool libffi ncurses readline"
 # add guile-native only to the target recipe's DEPENDS
 DEPENDS_append_class-target = " guile-native libatomics-ops"
 
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/8] libarchive: add PACKAGECONFIG for nettle

[Martin Jansa]

* fixes following floating dependencies:
  libarchive/libarchive/latest lost dependency on  nettle
  libarchive/libarchive-bin/latest lost dependency on  libxml2 nettle

Signed-off-by: Martin Jansa 
---
 meta/recipes-extended/libarchive/libarchive_3.1.2.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-extended/libarchive/libarchive_3.1.2.bb 
b/meta/recipes-extended/libarchive/libarchive_3.1.2.bb
index 2a2d0f9..96e2d50 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.1.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.1.2.bb
@@ -27,6 +27,7 @@ PACKAGECONFIG[openssl] = 
"--with-openssl,--without-openssl,openssl,"
 PACKAGECONFIG[libxml2] = "--with-xml2,--without-xml2,libxml2,"
 PACKAGECONFIG[expat] = "--with-expat,--without-expat,expat,"
 PACKAGECONFIG[lzo] = "--with-lzo2,--without-lzo2,lzo,"
+PACKAGECONFIG[nettle] = "--with-nettle,--without-nettle,nettle,"
 
 SRC_URI = "http://libarchive.org/downloads/libarchive-${PV}.tar.gz \
file://libarchive-CVE-2013-0211.patch \
-- 
2.0.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] State of bitbake world, Failed tasks 2014-08-08

[Martin Jansa]

http://www.openembedded.org/wiki/Bitbake_World_Status

== Failed tasks 2014-08-09 ==

=== common () ===

=== common-x86 (2) ===
* meta-browser/recipes-browser/chromium/chromium_35.0.1916.114.bb, 
do_compile
* meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile

=== qemuarm (0) ===

=== qemux86 (0) ===

=== qemux86_64 (1) ===
* meta-qt5/recipes-qt/qt5/qtwebengine_git.bb, do_compile

=== Number of failed tasks ===
{| class=wikitable
|-
||qemuarm   ||0 
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140808_202021.log/||
|-
||qemux86   ||2 
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140808_215005.log/||
|-
||qemux86_64||3 
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140809_154918.log/||http://errors.yoctoproject.org:80/Errors/Search/1/1694/
|}

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] lib/oeqa/selftest: Don't match log level in output

[Tyler Hall]

To facilitate changing the log level of the "Fetcher failure" message,
search only for the message without the "Error:" prefix.
---
 meta/lib/oeqa/selftest/bbtests.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/bbtests.py 
b/meta/lib/oeqa/selftest/bbtests.py
index e765e36..68f97bd 100644
--- a/meta/lib/oeqa/selftest/bbtests.py
+++ b/meta/lib/oeqa/selftest/bbtests.py
@@ -102,7 +102,7 @@ class BitbakeTests(oeSelfTest):
 bitbake('-ccleanall man')
 self.delete_recipeinc('man')
 self.assertEqual(result.status, 1, msg='Command succeded when it 
should have failed')
-self.assertTrue('ERROR: Fetcher failure: Unable to find file 
file://invalid anywhere. The paths that were searched were:' in result.output)
+self.assertTrue('Fetcher failure: Unable to find file file://invalid 
anywhere. The paths that were searched were:' in result.output)
 self.assertTrue('ERROR: Function failed: Fetcher failure for URL: 
\'file://invalid\'. Unable to fetch URL from any source.' in result.output)
 
 @testcase(171)
-- 
2.0.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] Fix TOCTOU issue with sstate mirror

[Tyler Hall]

When attempting to use sstate from a mirror, the siginfo file will be checked
twice: first when deciding whether to run the setscene task and again while
fetching in the setscene task. If the file is removed from the mirror between
those two checks, the setscene task will run and fail. This is acceptable since
since the real task will be run instead, but currently the fetcher will emit an
error message which causes bitbake to return a nonzero exit code. The build
completes successfully but appears to have failed.

This race has occurred several times in practice when using an http sstate
server that periodically prunes old files.

The simple fix provided here is to downgrade the internal fetcher error message
to a warning and let the do_fetch task continue to generate its error level
message.

This is one of two paches. First openembedded-core must be patched to ignore
the "Error:" prefix when scraping the log for this message. Then bitbake's log
level can change.

Tyler Hall (1):
  lib/oeqa/selftest: Don't match log level in output

 meta/lib/oeqa/selftest/bbtests.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.0.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] puzzled about definition of "build" task

[Robert P. J. Day]

  first time i noticed this in base.bbclass:

addtask build after do_populate_sysroot
do_build = "" <--- 
do_build[func] = "1"
do_build[noexec] = "1"
do_build[recrdeptask] += "do_deploy"
do_build () {
:
}

  what's with the lines

do_build = ""
do_build[func] = "1"

i've never seen that construct with any other tasks.

rday

-- 


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

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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] puzzled about definition of "build" task

[Christopher Larson]

On Sat, Aug 9, 2014 at 5:42 PM, Robert P. J. Day 
wrote:

>   first time i noticed this in base.bbclass:
>
> addtask build after do_populate_sysroot
> do_build = "" <--- 
> do_build[func] = "1"
> do_build[noexec] = "1"
> do_build[recrdeptask] += "do_deploy"
> do_build () {
> :
> }
>
>   what's with the lines
>
> do_build = ""
> do_build[func] = "1"
>
> i've never seen that construct with any other tasks.
>

I believe this was a remnant, from before bitbake started disliking empty
tasks. The "" and func = 1 bit defined it as a function but whose contents
were the empty string, but that's not something bitbake likes anymore,
hence the new definition with the :. See the git-blame info for those lines
to see the commits that last touched them: `git blame '-L/^do_build/,/^}/'
meta/classes/base.bbclass`
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core