Re: [OE-core] [PATCH] gnupg: specify explicitly tar path

[Wenlin Kang]

On 2016年12月20日 17:47, Wenlin Kang wrote:

On 2016年12月19日 19:39, Burton, Ross wrote:


On 19 December 2016 at 07:01, Wenlin Kang > wrote:


+- AC_PATH_PROG(TAR,"tar")
+-_mytar=$ac_cv_path_TAR


You don't need to patch configure.ac  as you can 
just set pass ac_cv_path_TAR=${base_bindir/tar in EXTRA_OECONF.


Ross


Your means is that we should only set --with-tar=${base_bindir}/tar in 
EXTRA_OECONF, not to modify configure.ac, right?
If that, the configure code will skip directly "ustar format check 
code", not check whether tar supports "ustar format",
and think it doesn't support ustar format, so I think we need to 
modify the configure(related m4/tar-ustar.m4 file)

when set  --with-tar=${base_bindir}/tar in EXTRA_OECONF.



   Hi Ross

   Do you have any thoughts for above my explain? and can you merge 
that patch to oecore ? thanks.



--
Thanks,
Wenlin Kang





--
Thanks,
Wenlin Kang

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

Re: [OE-core] SRCPV and git

[Paul Eggleton]

Hi Joe,

On Wed, 18 Jan 2017 01:07:15 Slater, Joseph wrote:
> I believe that SRCPV for a git SRC_URI always contains the string AUTOINC. 
> This could be considered wrong, or just misleading, since SRCREV can be set
> to a sha.  I think I might have brought this up in the past, but I cannot
> remember if there is some reason to retain the AUTOINC unconditionally.

I'll just paste this FAQ link - not that I'd expect anyone to have found this 
since it's still an unofficial FAQ, just to save me typing out the same thing:

  
https://wiki.yoctoproject.org/wiki/Technical_FAQ#Why_is_bitbake_showing_.22AUTOINC.22_in_the_version_for_some_recipes.3F

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] oeqa/selftest: Adds test case for sdk-update eSDK

[Francisco Pedraza]

1. Test case adds perl recipe before build eSDK.
2. After this added recipe, the script verifies the update:

${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.sh
oe-publish-sdk [esdk] [path-to-http]
CORE_IMAGE_EXTRA_INSTALL = "perl"
bitbake -c populate-sdk-ext [some-image]
devtool sdk-update

This should fix [YOCTO #9369]

Signed-off-by: Francisco Pedraza 
---
 meta/lib/oeqa/selftest/eSDK.py | 42 --
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/selftest/eSDK.py b/meta/lib/oeqa/selftest/eSDK.py
index b43a452..c95ca6d 100644
--- a/meta/lib/oeqa/selftest/eSDK.py
+++ b/meta/lib/oeqa/selftest/eSDK.py
@@ -51,6 +51,29 @@ class oeSDKExtSelfTest(oeSelfTest):
 toolchain_name = get_bb_var('TOOLCHAINEXT_OUTPUTNAME', pn_task)
 return os.path.join(sdk_deploy, toolchain_name + '.sh')
 
+@staticmethod
+def update_configuration(cls, image, tmpdir_eSDKQA, env_eSDK, 
ext_sdk_path):
+sstate_dir = os.path.join(os.environ['BUILDDIR'], 'sstate-cache')
+cls.http_service = HTTPService(sstate_dir)
+cls.http_service.start()
+cls.http_url = "http://127.0.0.1:%d; % cls.http_service.port
+
+oeSDKExtSelfTest.generate_eSDK(cls.image)
+
+cls.ext_sdk_path = oeSDKExtSelfTest.get_eSDK_toolchain(cls.image)
+runCmd("%s -y -d \"%s\"" % (cls.ext_sdk_path, cls.tmpdir_eSDKQA))
+
+cls.env_eSDK = oeSDKExtSelfTest.get_esdk_environment('', 
cls.tmpdir_eSDKQA)
+   
+sstate_config="""
+SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
+SSTATE_MIRRORS =  "file://.* http://%s/PATH;
+CORE_IMAGE_EXTRA_INSTALL = "perl"
+""" % cls.http_url
+
+with open(os.path.join(cls.tmpdir_eSDKQA, 'conf', 'local.conf'), 'a+') 
as f:
+f.write(sstate_config)
+
 
 @classmethod
 def setUpClass(cls):
@@ -59,16 +82,16 @@ class oeSDKExtSelfTest(oeSelfTest):
 cls.http_service = HTTPService(sstate_dir)
 cls.http_service.start()
 
-http_url = "127.0.0.1:%d" % cls.http_service.port
+cls.http_url = "http://127.0.0.1:%d; % cls.http_service.port
  
-image = 'core-image-minimal'
+cls.image = 'core-image-minimal'
 
 cls.tmpdir_eSDKQA = tempfile.mkdtemp(prefix='eSDKQA')
-oeSDKExtSelfTest.generate_eSDK(image)
+oeSDKExtSelfTest.generate_eSDK(cls.image)
 
 # Install eSDK
-ext_sdk_path = oeSDKExtSelfTest.get_eSDK_toolchain(image)
-runCmd("%s -y -d \"%s\"" % (ext_sdk_path, cls.tmpdir_eSDKQA))
+cls.ext_sdk_path = oeSDKExtSelfTest.get_eSDK_toolchain(cls.image)
+runCmd("%s -y -d \"%s\"" % (cls.ext_sdk_path, cls.tmpdir_eSDKQA))
 
 cls.env_eSDK = oeSDKExtSelfTest.get_esdk_environment('', 
cls.tmpdir_eSDKQA)
 
@@ -76,7 +99,7 @@ class oeSDKExtSelfTest(oeSelfTest):
 sstate_config="""
 SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
 SSTATE_MIRRORS =  "file://.* http://%s/PATH;
-""" % http_url
+""" % cls.http_url
 with open(os.path.join(cls.tmpdir_eSDKQA, 'conf', 'local.conf'), 'a+') 
as f:
 f.write(sstate_config)
 
@@ -99,5 +122,12 @@ SSTATE_MIRRORS =  "file://.* http://%s/PATH;
 cmd = "devtool build-image %s" % image
 oeSDKExtSelfTest.run_esdk_cmd(self.env_eSDK, self.tmpdir_eSDKQA, cmd)
 
+@testcase(1567)
+def test_sdk_update_http(self):
+cmd = "devtool sdk-update %s" % self.http_url
+oeSDKExtSelfTest.update_configuration(self, self.image, 
self.tmpdir_eSDKQA, self.env_eSDK, self.ext_sdk_path)
+oeSDKExtSelfTest.run_esdk_cmd(self.env_eSDK, self.tmpdir_eSDKQA, cmd)
+self.http_service.stop()
+
 if __name__ == '__main__':
 unittest.main()
-- 
2.5.0

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

[OE-core] SRCPV and git

[Slater, Joseph]

I believe that SRCPV for a git SRC_URI always contains the string AUTOINC.  
This could be considered
wrong, or just misleading, since SRCREV can be set to a sha.  I think I might 
have brought this up
in the past, but I cannot remember if there is some reason to retain the 
AUTOINC unconditionally.

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

Re: [OE-core] [PATCH 1/3] alsa-lib: update 1.1.2 -> 1.1.3

[Burton, Ross]

Apologies, queued locally.

Ross

On 17 January 2017 at 22:30, Andreas Müller 
wrote:

> Ping on this series + follow up
>
> 'alsa-utils(-scripts): fix compile on build machines with
> python-docutils installed'
>
> Andreas
> --
> ___
> 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 v1] oeqa/selftest: Adds test case for sdk-update eSDK

[Francisco Pedraza]

1. Test case adds perl recipe before build eSDK.
2. After this added recipe, the script verifies the update:
${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.sh
oe-publish-sdk [esdk] [path-to-http]
CORE_IMAGE_EXTRA_INSTALL = "perl"
bitbake -c populate-sdk-ext [some-image]
devtool sdk-update

This should fix [YOCTO #9369]
Signed-off-by: Francisco Pedraza 
---
 meta/lib/oeqa/selftest/eSDK.py | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/meta/lib/oeqa/selftest/eSDK.py b/meta/lib/oeqa/selftest/eSDK.py
index 83d5d52..c31bb60 100644
--- a/meta/lib/oeqa/selftest/eSDK.py
+++ b/meta/lib/oeqa/selftest/eSDK.py
@@ -51,6 +51,29 @@ class oeSDKExtSelfTest(oeSelfTest):
 toolchain_name = get_bb_var('TOOLCHAINEXT_OUTPUTNAME', pn_task)
 return os.path.join(sdk_deploy, toolchain_name + '.sh')
 
+@staticmethod
+def update_configuration(cls, image, tmpdir_eSDKQA, env_eSDK, 
ext_sdk_path):
+sstate_dir = os.path.join(os.environ['BUILDDIR'], 'sstate-cache')
+cls.http_service = HTTPService(sstate_dir)
+cls.http_service.start()
+cls.http_url = "http://127.0.0.1:%d; % cls.http_service.port
+
+oeSDKExtSelfTest.generate_eSDK(cls.image)
+
+cls.ext_sdk_path = oeSDKExtSelfTest.get_eSDK_toolchain(cls.image)
+runCmd("%s -y -d \"%s\"" % (cls.ext_sdk_path, cls.tmpdir_eSDKQA))
+
+cls.env_eSDK = oeSDKExtSelfTest.get_esdk_environment('', 
cls.tmpdir_eSDKQA)
+   
+sstate_config="""
+SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
+SSTATE_MIRRORS =  "file://.* http://%s/PATH;
+CORE_IMAGE_EXTRA_INSTALL = "perl"
+""" % cls.http_url
+
+with open(os.path.join(cls.tmpdir_eSDKQA, 'conf', 'local.conf'), 'a+') 
as f:
+f.write(sstate_config)
+
 
 @classmethod
 def setUpClass(cls):
@@ -61,14 +84,14 @@ class oeSDKExtSelfTest(oeSelfTest):
 
 cls.http_url = "http://127.0.0.1:%d; % cls.http_service.port
  
-image = 'core-image-minimal'
+cls.image = 'core-image-minimal'
 
 cls.tmpdir_eSDKQA = tempfile.mkdtemp(prefix='eSDKQA')
-oeSDKExtSelfTest.generate_eSDK(image)
+oeSDKExtSelfTest.generate_eSDK(cls.image)
 
 # Install eSDK
-ext_sdk_path = oeSDKExtSelfTest.get_eSDK_toolchain(image)
-runCmd("%s -y -d \"%s\"" % (ext_sdk_path, cls.tmpdir_eSDKQA))
+cls.ext_sdk_path = oeSDKExtSelfTest.get_eSDK_toolchain(cls.image)
+runCmd("%s -y -d \"%s\"" % (cls.ext_sdk_path, cls.tmpdir_eSDKQA))
 
 cls.env_eSDK = oeSDKExtSelfTest.get_esdk_environment('', 
cls.tmpdir_eSDKQA)
 
@@ -76,7 +99,6 @@ class oeSDKExtSelfTest(oeSelfTest):
 sstate_config="""
 SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
 SSTATE_MIRRORS =  "file://.* http://%s/PATH;
-CORE_IMAGE_EXTRA_INSTALL = "perl"
 """ % cls.http_url
 with open(os.path.join(cls.tmpdir_eSDKQA, 'conf', 'local.conf'), 'a+') 
as f:
 f.write(sstate_config)
@@ -101,9 +123,11 @@ CORE_IMAGE_EXTRA_INSTALL = "perl"
 oeSDKExtSelfTest.run_esdk_cmd(self.env_eSDK, self.tmpdir_eSDKQA, cmd)
 
 @testcase(1567)
-def test_sdk_update_http(cls):
-cmd = "devtool sdk-update %s" % cls.http_url
-oeSDKExtSelfTest.run_esdk_cmd(cls.env_eSDK, cls.tmpdir_eSDKQA, cmd)
+def test_sdk_update_http(self):
+cmd = "devtool sdk-update %s" % self.http_url
+oeSDKExtSelfTest.update_configuration(self, self.image, 
self.tmpdir_eSDKQA, self.env_eSDK, self.ext_sdk_path)
+oeSDKExtSelfTest.run_esdk_cmd(self.env_eSDK, self.tmpdir_eSDKQA, cmd)
+self.http_service.stop()
 
 if __name__ == '__main__':
 unittest.main()
-- 
2.5.0

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

Re: [OE-core] [PATCH v2] xserver-xorg: Enable glamor by default

[Burton, Ross]

On 12 January 2017 at 23:33, Saul Wold  wrote:

> To enable glamor, we need to also enable both dri3 and xshmfence as
> dependencies.
>

Of course musl's lack of lazy loading bits xserver again:

[ 8.655] (EE) Failed to load
/usr/lib/xorg/modules/drivers/modesetting_drv.so: Error relocating
/usr/lib/xorg/modules/drivers/modesetting_drv.so: glamor_set_screen_pixmap:
symbol not found

xserver-xf86-config has a config fragment that loads a set of modules on
startup if musl is enabled, I'm guessing glamoregl should be on that list?

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

Re: [OE-core] [PATCH 1/3] alsa-lib: update 1.1.2 -> 1.1.3

[Andreas Müller]

Ping on this series + follow up

'alsa-utils(-scripts): fix compile on build machines with
python-docutils installed'

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

Re: [OE-core] [PATCH] runqemu: Allow the user to specity no kernel or rootFS

[Alistair Francis]

On Tue, Jan 10, 2017 at 1:04 PM, Alistair Francis
 wrote:
> In some cirsumstances the user doesn't want to supply a kernel, rootFS
> or DTB to QEMU. This will occur more now that QEMU supports loading
> images using a '-device loader' method.
>
> Allow users to specify 'none' for QB_DEFAULT_FSTYPE or QB_DEFAULT_KERNEL
> to avoid supplying these options to QEMU.

Is there any possibility of back porting this to Morty as well?

Thanks,

Alistair

>
> Signed-off-by: Alistair Francis 
> ---
> Nathan Rossi previously queried if we should have a QB_KERNEL_OPT
> variable instead of this, so then different machines can set that
> based on their specifc use cases. Generally it would be set to
> QB_KERNEL_OPT = "-kernel @KERNEL@".
>
> I never heard any feedback on that and as it would break all
> existing QEMU usage I haven't changed this patch to do that.
>
>  scripts/runqemu | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index 203992a..83ec337 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -453,7 +453,7 @@ class BaseConfig(object):
>  def check_rootfs(self):
>  """Check and set rootfs"""
>
> -if self.fstype == 'nfs':
> +if self.fstype == 'nfs' or self.fstype == "none":
>  return
>
>  if self.rootfs and not os.path.exists(self.rootfs):
> @@ -481,6 +481,10 @@ class BaseConfig(object):
>  # QB_DEFAULT_KERNEL is always a full file path
>  kernel_name = os.path.basename(self.get('QB_DEFAULT_KERNEL'))
>
> +# The user didn't want a kernel to be loaded
> +if kernel_name == "none":
> +return
> +
>  deploy_dir_image = self.get('DEPLOY_DIR_IMAGE')
>  if not self.kernel:
>  kernel_match_name = "%s/%s" % (deploy_dir_image, kernel_name)
> @@ -858,6 +862,9 @@ class BaseConfig(object):
>  k_root = '/dev/nfs nfsroot=%s:%s,%s' % (self.nfs_server, 
> self.nfs_dir, self.unfs_opts)
>  self.kernel_cmdline = 'root=%s rw highres=off' % k_root
>
> +if self.fstype == 'none':
> +self.rootfs_options = ''
> +
>  self.set('ROOTFS_OPTIONS', self.rootfs_options)
>
>  def guess_qb_system(self):
> --
> 2.7.4
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] Patchwork and incoming patch testing

[Denys Dmytriyenko]

Paul,

That is some impressive work by the team! Thank you all for the hard work and 
bringing the plan to fruition - I'm sure this framework will benefit our 
entire Community and will improve and streamline the workflow!

-- 
Denys


On Wed, Jan 18, 2017 at 07:05:58AM +1300, Paul Eggleton wrote:
> Hi all,
> 
> As some of you are aware some of my colleagues and I have been working on 
> improving how incoming patches are handled - initially for OE-Core but we 
> hope 
> to arrive at something that will be useful for other layers as well. The aim 
> was to do so without adversely affecting existing workflows, so that means 
> building on top of the things we already have. It's taken a bit longer than 
> we'd originally planned - we embarked on this a little over a year ago [1] - 
> but now I am happy to be able to show some meaningful progress.
> 
> A few months ago we upgraded OE's patchwork instance [2], moving not just to 
> a 
> later version but to a fork of patchwork where a bunch of new functionality 
> was being developed for freedesktop.org [3], notably support for capturing 
> and 
> presenting patch series instead of just individual patches. There were some 
> teething problems but we've now resolved most of them. Unfortunately work on 
> said freedesktop.org fork appears to have stalled so for now we have forked 
> it 
> ourselves [4]; long term we'll have to see if we can merge back with 
> patchwork 
> upstream - at least for small fixes we'll try to push those back up 
> independent of any wholesale merge. In any event we are now finally in the 
> position where our patchwork instance can be relied upon to collect emails, 
> and the UI is much improved. This should give us a bit more visibility into 
> where patches are at in the process, although we are still working on a few 
> places where patch series status needs to be updated (e.g. when a patch goes 
> into testing).
> 
> On top of patchwork we have built a simple smoke-testing framework called 
> "patchtest" [5] along with a suite of corresponding tests for OE [6]. These 
> tests are fairly simplistic at this point but check the basics such as 
> whether 
> a patch has been properly signed off, etc. We should soon start seeing 
> replies 
> sent to the mailing list and to submitters with results if there are any 
> failures, saving us from noticing and pointing out some of the more obvious 
> classes of mistakes. The tests are easy to run locally without the rest of 
> the 
> infrastructure and can be extended without difficulty, and I expect we'll 
> continue to work on those as time progresses. Contributions would be very 
> welcome.
> 
> My sincere thanks to José Lamego, Leonardo Sandoval, Daniela Plascencia, 
> Belen Barros Pena, Michael Halstead, Damien Lespiau, Patrick Ohly and others 
> that have been part of implementing this, and to everyone else who has put up 
> with the delays.
> 
> Please let us know if you have issues with any part of this process or 
> suggestions on how to improve it. We're tracking improvements in the Yocto 
> Project bugzilla [7] so you can see what's being worked on there if you're 
> interested.
> 
> Cheers,
> Paul
> 
> [1] Earlier announcement:
> 
> https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg72952.html
> 
> [2] OE's patchwork instance:
> http://patchwork.openembedded.org
> 
> [3] Freedesktop.org patchwork fork:
> https://github.com/dlespiau/patchwork
> 
> [4] Our patchwork fork:
> http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/
> 
> [5] Patchtest main repository:
> http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/
> 
> [6] OE test suite for patchtest:
> http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/
> 
> [7] Yocto Project bugzilla area for patchwork/patchtest:
> 
> https://bugzilla.yoctoproject.org/describecomponents.cgi?product=Patchwork%2FPatchtest
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Patchwork and incoming patch testing

[Paul Eggleton]

Hi all,

As some of you are aware some of my colleagues and I have been working on 
improving how incoming patches are handled - initially for OE-Core but we hope 
to arrive at something that will be useful for other layers as well. The aim 
was to do so without adversely affecting existing workflows, so that means 
building on top of the things we already have. It's taken a bit longer than 
we'd originally planned - we embarked on this a little over a year ago [1] - 
but now I am happy to be able to show some meaningful progress.

A few months ago we upgraded OE's patchwork instance [2], moving not just to a 
later version but to a fork of patchwork where a bunch of new functionality 
was being developed for freedesktop.org [3], notably support for capturing and 
presenting patch series instead of just individual patches. There were some 
teething problems but we've now resolved most of them. Unfortunately work on 
said freedesktop.org fork appears to have stalled so for now we have forked it 
ourselves [4]; long term we'll have to see if we can merge back with patchwork 
upstream - at least for small fixes we'll try to push those back up 
independent of any wholesale merge. In any event we are now finally in the 
position where our patchwork instance can be relied upon to collect emails, 
and the UI is much improved. This should give us a bit more visibility into 
where patches are at in the process, although we are still working on a few 
places where patch series status needs to be updated (e.g. when a patch goes 
into testing).

On top of patchwork we have built a simple smoke-testing framework called 
"patchtest" [5] along with a suite of corresponding tests for OE [6]. These 
tests are fairly simplistic at this point but check the basics such as whether 
a patch has been properly signed off, etc. We should soon start seeing replies 
sent to the mailing list and to submitters with results if there are any 
failures, saving us from noticing and pointing out some of the more obvious 
classes of mistakes. The tests are easy to run locally without the rest of the 
infrastructure and can be extended without difficulty, and I expect we'll 
continue to work on those as time progresses. Contributions would be very 
welcome.

My sincere thanks to José Lamego, Leonardo Sandoval, Daniela Plascencia, 
Belen Barros Pena, Michael Halstead, Damien Lespiau, Patrick Ohly and others 
that have been part of implementing this, and to everyone else who has put up 
with the delays.

Please let us know if you have issues with any part of this process or 
suggestions on how to improve it. We're tracking improvements in the Yocto 
Project bugzilla [7] so you can see what's being worked on there if you're 
interested.

Cheers,
Paul

[1] Earlier announcement:

https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg72952.html

[2] OE's patchwork instance:
http://patchwork.openembedded.org

[3] Freedesktop.org patchwork fork:
https://github.com/dlespiau/patchwork

[4] Our patchwork fork:
http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/

[5] Patchtest main repository:
http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/

[6] OE test suite for patchtest:
http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/

[7] Yocto Project bugzilla area for patchwork/patchtest:

https://bugzilla.yoctoproject.org/describecomponents.cgi?product=Patchwork%2FPatchtest

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [morty][PATCH] linux-dtb: strip DTB extension properly in postinst/postrm

[Denys Dmytriyenko]

Ping

On Tue, Jan 10, 2017 at 06:11:39PM -0500, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> The use of awk -F "." in do_install/do_deploy to strip filename extension
> was deprecated long time ago in 72980d5bb465f0640ed451d1ebb9c5d2a210ad0c.
> 
> Make a similar change in postinst/postrm to properly use basename command.
> 
> Otherwise DTB files that contain dots in the name result in broken symlinks
> that point to non-existent truncated files.
> 
> Signed-off-by: Denys Dmytriyenko 
> Signed-off-by: Ross Burton 
> 
> (From OE-Core rev: 40c2addf0f0ee16b1c1334cf00f1490ffeaac475)
> 
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta/recipes-kernel/linux/linux-dtb.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
> b/meta/recipes-kernel/linux/linux-dtb.inc
> index 8528d64..2f378a1 100644
> --- a/meta/recipes-kernel/linux/linux-dtb.inc
> +++ b/meta/recipes-kernel/linux/linux-dtb.inc
> @@ -68,7 +68,7 @@ pkg_postinst_kernel-devicetree () {
>   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
>   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
>   DTB_EXT=${DTB##*.}
> - DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
> $1}'`
> + DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
>   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
> "s/${MACHINE}/${DTB_BASE_NAME}/g"`
>   update-alternatives --install 
> /${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} ${DTB_BASE_NAME}.${DTB_EXT} 
> /boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} ${KERNEL_PRIORITY} || true
>   done
> @@ -81,7 +81,7 @@ pkg_postrm_kernel-devicetree () {
>   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
>   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
>   DTB_EXT=${DTB##*.}
> - DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
> $1}'`
> + DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
>   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
> "s/${MACHINE}/${DTB_BASE_NAME}/g"`
>   update-alternatives --remove 
> ${DTB_BASE_NAME}.${DTB_EXT} /boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} 
> ${KERNEL_PRIORITY} || true
>   done
> -- 
> 2.7.4
> 
> -- 
> ___
> 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

Re: [OE-core] [morty][PATCH] attr/ea-acl: pass --disable-gettext when USE_NLS=no

[Denys Dmytriyenko]

Ping

On Tue, Jan 10, 2017 at 06:12:00PM -0500, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> Fixes following error in configure:
>   FATAL ERROR: msgfmt does not seem to be installed.
>   attr cannot be built without a working gettext installation.
> 
> Signed-off-by: Denys Dmytriyenko 
> Signed-off-by: Ross Burton 
> 
> (From OE-Core rev: d044fad8a0ac5d57deb88b25106f3a39cb7c1636)
> 
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta/recipes-support/attr/ea-acl.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-support/attr/ea-acl.inc 
> b/meta/recipes-support/attr/ea-acl.inc
> index 370e16f..0e2ede3 100644
> --- a/meta/recipes-support/attr/ea-acl.inc
> +++ b/meta/recipes-support/attr/ea-acl.inc
> @@ -10,6 +10,7 @@ inherit autotools-brokensep gettext
>  EXTRA_AUTORECONF += "--exclude=autoheader"
>  EXTRA_OECONF = "INSTALL_USER=root INSTALL_GROUP=root"
>  EXTRA_OECONF_append_class-native = " --enable-gettext=no"
> +EXTRA_OECONF_append_class-target = "${@['', ' --disable-gettext 
> '][(d.getVar('USE_NLS') == 'no')]}"
>  
>  EXTRA_OEMAKE = "PKG_LIB_DIR=${base_libdir} PKG_DEVLIB_DIR=${libdir}"
>  
> -- 
> 2.7.4
> 
> -- 
> ___
> 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

Re: [OE-core] [morty][PATCH] attr/ea-acl: pass --disable-gettext when USE_NLS=no

[Denys Dmytriyenko]

Sorry, ignore this one - there was v2 previously submitted specifically for 
morty.

On Tue, Jan 17, 2017 at 12:26:37PM -0500, Denys Dmytriyenko wrote:
> Ping
> 
> On Tue, Jan 10, 2017 at 06:12:00PM -0500, Denys Dmytriyenko wrote:
> > From: Denys Dmytriyenko 
> > 
> > Fixes following error in configure:
> >   FATAL ERROR: msgfmt does not seem to be installed.
> >   attr cannot be built without a working gettext installation.
> > 
> > Signed-off-by: Denys Dmytriyenko 
> > Signed-off-by: Ross Burton 
> > 
> > (From OE-Core rev: d044fad8a0ac5d57deb88b25106f3a39cb7c1636)
> > 
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> >  meta/recipes-support/attr/ea-acl.inc | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/recipes-support/attr/ea-acl.inc 
> > b/meta/recipes-support/attr/ea-acl.inc
> > index 370e16f..0e2ede3 100644
> > --- a/meta/recipes-support/attr/ea-acl.inc
> > +++ b/meta/recipes-support/attr/ea-acl.inc
> > @@ -10,6 +10,7 @@ inherit autotools-brokensep gettext
> >  EXTRA_AUTORECONF += "--exclude=autoheader"
> >  EXTRA_OECONF = "INSTALL_USER=root INSTALL_GROUP=root"
> >  EXTRA_OECONF_append_class-native = " --enable-gettext=no"
> > +EXTRA_OECONF_append_class-target = "${@['', ' --disable-gettext 
> > '][(d.getVar('USE_NLS') == 'no')]}"
> >  
> >  EXTRA_OEMAKE = "PKG_LIB_DIR=${base_libdir} PKG_DEVLIB_DIR=${libdir}"
> >  
> > -- 
> > 2.7.4
> > 
> > -- 
> > ___
> > 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

Re: [OE-core] [morty][PATCH v2] attr/ea-acl: pass --disable-gettext when USE_NLS=no

[Denys Dmytriyenko]

Ping

On Tue, Jan 10, 2017 at 07:21:28PM -0500, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> Fixes following error in configure:
>   FATAL ERROR: msgfmt does not seem to be installed.
>   attr cannot be built without a working gettext installation.
> 
> Signed-off-by: Denys Dmytriyenko 
> Signed-off-by: Ross Burton 
> 
> (From OE-Core rev: d044fad8a0ac5d57deb88b25106f3a39cb7c1636)
> 
> Signed-off-by: Denys Dmytriyenko 
> ---
> v2 - morty still requires expand option to d.getVar()
> 
>  meta/recipes-support/attr/ea-acl.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-support/attr/ea-acl.inc 
> b/meta/recipes-support/attr/ea-acl.inc
> index 370e16f..4d6ad20 100644
> --- a/meta/recipes-support/attr/ea-acl.inc
> +++ b/meta/recipes-support/attr/ea-acl.inc
> @@ -10,6 +10,7 @@ inherit autotools-brokensep gettext
>  EXTRA_AUTORECONF += "--exclude=autoheader"
>  EXTRA_OECONF = "INSTALL_USER=root INSTALL_GROUP=root"
>  EXTRA_OECONF_append_class-native = " --enable-gettext=no"
> +EXTRA_OECONF_append_class-target = "${@['', ' --disable-gettext 
> '][(d.getVar('USE_NLS', True) == 'no')]}"
>  
>  EXTRA_OEMAKE = "PKG_LIB_DIR=${base_libdir} PKG_DEVLIB_DIR=${libdir}"
>  
> -- 
> 2.7.4
> 
> -- 
> ___
> 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

Re: [OE-core] [PATCH 0/3] distutils3: add egg files to path

[Burton, Ross]

On 17 January 2017 at 15:42, Jose Lamego 
wrote:

> Packages that use egg files or directories for installation may
> not be found when imported at the python3 interpreter.
> egg files/directories path must be included in a pth file to
> be appropriately included in python path.
>

Do we understand why pip and distutils are installing as eggs, instead of
the traditional format?  I thought we
passed --single-version-externally-managed to setuptools to handle this but
I can't see this anywhere (Khem removed it from distutils back in 2013).
For reference, python3-mako just installs the metadata to the egg folder
and installs the Python code in the traditional way.

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

Re: [OE-core] [morty][PATCH] busybox: refresh the flock patch

[Burton, Ross]

On 17 January 2017 at 16:20, Maxin B. John  wrote:

> Upstream accepted the flock fix with some improvements. Backport those
> changes.
>

Thanks Maxin,

This also applies to master, and I've queued it in mut.

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

Re: [OE-core] [PATCH] python3-pygobject: enable cairo only when a display is available

[Andreas Müller]

On Tue, Jan 17, 2017 at 4:28 PM, André Draszik  wrote:
> From: André Draszik 
>
> It doesn't seem to make sense to unconditionally enable cairo
> support, as this pulls in lots of other dependencies, where
> none of these can actually be used without some sort of
> graphical interface.
>
> Not having a generic distro feature to detect this, we just
> use any of DirectFB / Wayland / X11
>
> Signed-off-by: André Draszik 
> ---
>  meta/recipes-devtools/python/python3-pygobject_3.22.0.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb 
> b/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb
> index 5a895441fc..143048d9ef 100644
> --- a/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb
> +++ b/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb
> @@ -19,7 +19,7 @@ SRC_URI[sha256sum] = 
> "08b29cfb08efc80f7a8630a2734dec65a99c1b59f1e5771c671d2e4ed8
>  S = "${WORKDIR}/${SRCNAME}-${PV}"
>
>
> -PACKAGECONFIG ??= "cairo"
> +PACKAGECONFIG ??= "${@bb.utils.contains_any('DISTRO_FEATURES', [ 'directfb', 
> 'wayland', 'x11' ], 'cairo', '', d)}"
>
>  # python3-pycairo is checked on configuration -> DEPENDS
>  # we don't link against python3-pycairo -> RDEPENDS
> --
> 2.11.0
>
Looks good

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

[OE-core] [morty][PATCH] busybox: refresh the flock patch

[Maxin B. John]

Upstream accepted the flock fix with some improvements. Backport those
changes.

Signed-off-by: Maxin B. John 
---
 ...e-the-behaviour-of-c-parameter-to-match-u.patch | 77 ++
 1 file changed, 34 insertions(+), 43 deletions(-)

diff --git 
a/meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
 
b/meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
index 8bcbd73..78520f0 100644
--- 
a/meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
+++ 
b/meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
@@ -1,35 +1,24 @@
-From 198f18addf1d814c2fefcb492f3b9fbd221669bb Mon Sep 17 00:00:00 2001
-From: "Maxin B. John" 
-Date: Wed, 20 Apr 2016 18:24:45 +0300
-Subject: [PATCH] flock: update the behaviour of -c parameter to match upstream
-
-In upstream, -c 'PROG ARGS' means "run sh -c 'PROG ARGS'"
+From e1d426fd65c00a6d01a10d85edf8a294ae8a2d2b Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Sun, 24 Apr 2016 18:19:49 +0200
+Subject: [PATCH] flock: fix -c; improve error handling of fork+exec
 
 function old new   delta
-flock_main   286 377 +91
-.rodata   155849  155890 +41
+flock_main   254 334 +80
 
-Upstream-Status: Submitted
-[ http://lists.busybox.net/pipermail/busybox/2016-April/084142.html ]
+Upstream-Status: Backport
 
+Signed-off-by: Denys Vlasenko 
 Signed-off-by: Maxin B. John 
 ---
- util-linux/flock.c | 20 ++--
- 1 file changed, 14 insertions(+), 6 deletions(-)
+ util-linux/flock.c | 19 +--
+ 1 file changed, 17 insertions(+), 2 deletions(-)
 
 diff --git a/util-linux/flock.c b/util-linux/flock.c
-index 05a747f..c85a25d 100644
+index 05a747f..539a835 100644
 --- a/util-linux/flock.c
 +++ b/util-linux/flock.c
-@@ -20,6 +20,7 @@ int flock_main(int argc, char **argv) 
MAIN_EXTERNALLY_VISIBLE;
- int flock_main(int argc UNUSED_PARAM, char **argv)
- {
-   int mode, opt, fd;
-+char *cmd_args[4];
-   enum {
-   OPT_s = (1 << 0),
-   OPT_x = (1 << 1),
-@@ -57,7 +58,6 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
+@@ -57,7 +57,6 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
/* If it is "flock FILE -c PROG", then -c isn't caught by getopt32:
 * we use "+" in order to support "flock -opt FILE PROG -with-opts",
 * we need to remove -c by hand.
@@ -37,35 +26,37 @@ index 05a747f..c85a25d 100644
 */
if (argv[0]
 && argv[0][0] == '-'
-@@ -65,7 +65,10 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
-   || (ENABLE_LONG_OPTS && strcmp(argv[0] + 1, "-command") == 0)
+@@ -66,6 +65,9 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
)
) {
--  argv++;
-+if (argc != optind + 3)
-+bb_error_msg_and_die("-c requires exactly one command argument");
-+else
-+argv++;
+   argv++;
++  if (argv[1])
++  bb_error_msg_and_die("-c takes only one argument");
++  opt |= OPT_c;
}
  
if (OPT_s == LOCK_SH && OPT_x == LOCK_EX && OPT_n == LOCK_NB && OPT_u 
== LOCK_UN) {
-@@ -89,9 +92,14 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
-   return EXIT_FAILURE;
+@@ -90,8 +92,21 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
bb_perror_nomsg_and_die();
}
--
+ 
 -  if (argv[0])
--  return spawn_and_wait(argv);
--
-+if (argv[0]) {
-+cmd_args[0] = getenv("SHELL");
-+if (!cmd_args[0])
-+cmd_args[0] = (char*)DEFAULT_SHELL;
-+cmd_args[1] = (char*)"-c";
-+cmd_args[2] = argv[0];
-+cmd_args[3] = NULL;
-+return spawn_and_wait(cmd_args);
-+}
++  if (argv[0]) {
++  if (!(opt & OPT_c)) {
++  int rc = spawn_and_wait(argv);
++  if (rc < 0)
++  bb_simple_perror_msg(argv[0]);
++  return rc;
++  }
++  /* -c 'PROG ARGS' means "run sh -c 'PROG ARGS'" */
++  argv -= 2;
++  argv[0] = (char*)get_shell_name();
++  argv[1] = (char*)"-c";
++  /* argv[2] = "PROG ARGS"; */
++  /* argv[3] = NULL; */
+   return spawn_and_wait(argv);
++  }
+ 
return EXIT_SUCCESS;
  }
 -- 
-- 
2.4.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

[OE-core] Yocto Project Status WW03’17

[Jolley, Stephen K]

Current Dev Position: YP 2.3 M2

Next Deadline: YP 2.3 M2 by Jan 23, 2017


SWAT team rotation: Armin -> Saul on Jan. 13, 2017.

SWAT team rotation: Saul -> Paul on Jan. 20, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·The 2.2.1 release has been held up by a bug in eSDK which we’re having 
trouble tracking down, it is fixed in master but we’re not sure where/how. 
We’ll rebuild and submit to QA once we find it.

·The M2 deadline is at the end of the week. The oeqa patchset should be 
posted imminently once the final bugs that testing has discovered are fixed. 
There is an update about recipe specific sysroot that will be sent to the 
openembedded-architecture list shortly but good progress is also being made 
there with a handful of test cases showing issues that still need to be 
resolved. We don’t yet have performance data on the sysroot changes which is 
one potential problem still to be determined.

·We continue to struggle with stabilizing patches coming in from the 
mailing list and whilst patches are merging, its taking longer to review and 
test them that we’d like and the flow is slower than it would ideally be.

·One particular challenge we’re facing is the length of time 
oe-selftest takes to run. A bitbake change from Jianxun Zhang has sped up the 
bitbake -S based sstate tests significantly which is a start at improving its 
speed, we also found an issue that slowed down test case loading but there are 
many more things which can be done to speed this up and it's an area we’ll need 
to focus on if we want to improve overall patch throughput.


Proposed upcoming dot releases:

YP 2.2.1 Release by Jan. 20, 2017 (Will be late)

YP 2.1.3 Cut off May 8, 2017

YP 2.1.3 Release by May 19, 2017

YP 2.2.2 Cut off May 22, 2017

YP 2.2.2 Release by June 2, 2017


Key YP 2.3 Dates:

YP 2.3 M2 Cutoff is Jan. 23, 2017

YP 2.3 M2 Release is Feb. 3, 2017

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 3, 2017

YP 2.3 M4 Release is April 28, 2017


Tracking Metrics:

WDD 2624 (last week 2632)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

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

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

[OE-core] [PATCH] time: BBCLASSEXTEND to native and nativesdk

[André Draszik]

From: André Draszik 

Some recipe might use time, e.g.
  
http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd/tree/classes/swupd-image.bbclass?id=531a8e636ca891c34f2596eb7f6365a11d4b29a7#n481
Time is a bash built-in, or a separate utility (typically
in /usr/bin/), but not everybody uses bash, or has
GNU time installed by default.

Signed-off-by: André Draszik 
---
 meta/recipes-extended/time/time.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/time/time.inc 
b/meta/recipes-extended/time/time.inc
index 85862177b7..6b20d7c520 100644
--- a/meta/recipes-extended/time/time.inc
+++ b/meta/recipes-extended/time/time.inc
@@ -10,3 +10,5 @@ inherit texinfo update-alternatives
 
 ALTERNATIVE_${PN} = "time"
 ALTERNATIVE_PRIORITY = "100"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.11.0

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

[OE-core] [PATCH 2/3] python3-pip: Remove pth file creation at recipe level

[Jose Lamego]

Handling of installed eggs is now performed at the distutils3 bbclass.

This change removes the pth file creation at recipe level.

[YOCTO #8673]

Signed-off-by: Jose Lamego 
---
 meta/recipes-devtools/python/python3-pip_9.0.1.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-pip_9.0.1.bb 
b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
index 6ac94bb..9dce107 100644
--- a/meta/recipes-devtools/python/python3-pip_9.0.1.bb
+++ b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
@@ -31,9 +31,6 @@ do_install_append() {
 
 # Install as pip3 and leave pip2 as default
 rm ${D}/${bindir}/pip
-
-# Installed eggs need to be passed directly to the interpreter via a pth 
file
-echo "./${SRCNAME}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
${D}${PYTHON_SITEPACKAGES_DIR}/${SRCNAME}-${PV}.pth
 }
 
 RDEPENDS_${PN} = "\
-- 
1.8.3.1

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

[OE-core] [PATCH 1/3] distutils3.bbclass: add egg files/directories to python path

[Jose Lamego]

Packages that use .egg files or directories for installation may
not be found when imported at the python3 interpreter.
.egg files/directories path must be included in a .pth file to
be appropriately included in python path.

This change looks for .egg files/directories in sitepackages
and adds its path to a .pth file during package installation.
It ensures that any new package that uses .egg files/recipes
will be appropriately added to path by performing the check from
the distutils3 class.

[YOCTO #8673]

Signed-off-by: Jose Lamego 
---
 meta/classes/distutils3.bbclass | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index a6720c5..f8e2e2e 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -68,6 +68,16 @@ distutils3_do_install() {
 mv -f ${D}${datadir}/share/* ${D}${datadir}/
 rmdir ${D}${datadir}/share
 fi
+
+# detect if .egg files/directories were created and add their
+# path to a .pth file
+SHORT_PN=$(echo "${PN}" | sed 's/${PYTHON_PN}-//g')
+if test -e ${D}${PYTHON_SITEPACKAGES_DIR}/${SHORT_PN}*.egg; then
+EGG_NAME=$(basename $(find ${D}${PYTHON_SITEPACKAGES_DIR}/ \
+-name ${SHORT_PN}\*.egg))
+echo "./${EGG_NAME}" > ${D}${PYTHON_SITEPACKAGES_DIR}/\
+${SHORT_PN}.pth
+fi
 }
 distutils3_do_install[vardepsexclude] = "MACHINE"
 
-- 
1.8.3.1

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

[OE-core] [PATCH 0/3] distutils3: add egg files to path

[Jose Lamego]

Packages that use egg files or directories for installation may
not be found when imported at the python3 interpreter.
egg files/directories path must be included in a pth file to
be appropriately included in python path.

These changes handle the egg files from the distutils3 class to avoid
the need to perform it individually at each recipe.

[YOCTO #8673]

The following changes since commit 63f899a950daf1018999455bafa7a2be8b22f164:

  bitbake: toaster: bin/toaster whitelist TOASTER_DIR (2017-01-17 13:18:47 
+)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib lamego/bug8673
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lamego/bug8673

Jose Lamego (3):
  distutils3.bbclass: add egg files/directories to python path
  python3-pip: Remove pth file creation at recipe level
  python3-setuptools: Remove pth file creation at recipe level

 meta/classes/distutils3.bbclass   | 10 ++
 meta/recipes-devtools/python/python3-pip_9.0.1.bb |  3 ---
 meta/recipes-devtools/python/python3-setuptools_31.0.0.bb |  3 ---
 3 files changed, 10 insertions(+), 6 deletions(-)

-- 
1.8.3.1

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

[OE-core] [PATCH 3/3] python3-setuptools: Remove pth file creation at recipe level

[Jose Lamego]

Handling of installed eggs is now performed at the distutils3 bbclass.

This change removes the pth file creation at recipe level.

[YOCTO #8673]

Signed-off-by: Jose Lamego 
---
 meta/recipes-devtools/python/python3-setuptools_31.0.0.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb 
b/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb
index 65af6f0..b37b381 100644
--- a/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb
@@ -7,11 +7,8 @@ inherit distutils3
 
 DISTUTILS_INSTALL_ARGS += "--install-lib=${D}${PYTHON_SITEPACKAGES_DIR}"
 
-# The installer puts the wrong path in the setuptools.pth file.  Correct it.
 do_install_append() {
-rm ${D}${PYTHON_SITEPACKAGES_DIR}/setuptools.pth
 mv ${D}${bindir}/easy_install ${D}${bindir}/easy3_install
-echo "./${SRCNAME}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
${D}${PYTHON_SITEPACKAGES_DIR}/setuptools.pth
 }
 
 RDEPENDS_${PN} = "\
-- 
1.8.3.1

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

[OE-core] [PATCH] python3-pygobject: enable cairo only when a display is available

[André Draszik]

From: André Draszik 

It doesn't seem to make sense to unconditionally enable cairo
support, as this pulls in lots of other dependencies, where
none of these can actually be used without some sort of
graphical interface.

Not having a generic distro feature to detect this, we just
use any of DirectFB / Wayland / X11

Signed-off-by: André Draszik 
---
 meta/recipes-devtools/python/python3-pygobject_3.22.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb 
b/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb
index 5a895441fc..143048d9ef 100644
--- a/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb
+++ b/meta/recipes-devtools/python/python3-pygobject_3.22.0.bb
@@ -19,7 +19,7 @@ SRC_URI[sha256sum] = 
"08b29cfb08efc80f7a8630a2734dec65a99c1b59f1e5771c671d2e4ed8
 S = "${WORKDIR}/${SRCNAME}-${PV}"
 
 
-PACKAGECONFIG ??= "cairo"
+PACKAGECONFIG ??= "${@bb.utils.contains_any('DISTRO_FEATURES', [ 'directfb', 
'wayland', 'x11' ], 'cairo', '', d)}"
 
 # python3-pycairo is checked on configuration -> DEPENDS
 # we don't link against python3-pycairo -> RDEPENDS
-- 
2.11.0

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

Re: [OE-core] [PATCH] busybox: update flock behavior to match upstream

[Maxin B. John]

Hi,

On Tue, Jan 17, 2017 at 12:59:37PM +, Phil Blundell wrote:
> On Thu, 2016-04-21 at 12:24 +0300, Maxin B. John wrote:
> > 
> +-
> > +-  if (argv[0])
> > +-  return spawn_and_wait(argv);
> > +-
> > ++if (argv[0]) {
> > ++cmd_args[0] = getenv("SHELL");
> > ++if (!cmd_args[0])
> > ++cmd_args[0] = (char*)DEFAULT_SHELL;
> > ++cmd_args[1] = (char*)"-c";
> > ++cmd_args[2] = argv[0];
> > ++cmd_args[3] = NULL;
> > ++return spawn_and_wait(cmd_args);
> > ++}
> > +   return EXIT_SUCCESS;
> > + }
> > 
> 
> This patch seems to completely break the behaviour of flock when
> invoked without "-c".  For example, compare the behaviour of:
> 
> flock /tmp/lock echo it works
> 
> before and after.  Please revert this patch until and unless it can be
> fixed.

My bad. Thanks for noticing this. Upstream accepted the patch with some
improvements to fix this:
https://git.busybox.net/busybox/commit/?id=e1d426fd65c00a6d01a10d85edf8a294ae8a2d2b

I will backport that patch and send it soon.

> p.

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

Re: [OE-core] [PATCH] busybox: update flock behavior to match upstream

[Burton, Ross]

On 17 January 2017 at 12:59, Phil Blundell  wrote:

> before and after.  Please revert this patch until and unless it can be
> fixed.
>

Reverted locally.  Maxin, can you have a look at this?

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

Re: [OE-core] [PATCH V2 0/6] runqemu: fix for slirp, network device and hostfwd

[Burton, Ross]

Hi Robert,

I merged these into my staging branch but then the autobuilder failed in an
interesting way:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/1053/steps/Running%20Sanity%20Tests/logs/stdio

Would that be related to your series, or is it a coincidence?

Ross

On 11 January 2017 at 01:47, Robert Yang  wrote:

> ping.
>
> // Robert
>
>
> On 12/21/2016 02:24 PM, Robert Yang wrote:
>
>> Hi Ross,
>>
>> I rebased in the repo:
>>
>>  git://git.openembedded.org/openembedded-core-contrib rbt/runqemu
>>
>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-cont
>> rib/log/?h=rbt/runqemu
>>
>> Robert Yang (6):
>>   scripts/runqemu: fix checking for .cpio.gz
>>   qemuboot.bbclass: use IMGDEPLOYDIR
>>   runqemu-export-rootfs: fix inconsistent var names
>>   runqemu: support mutiple qemus running when nfs
>>   runqemu: fixes for slirp, network device and hostfwd
>>   qemuboot.bbclass: add blank lines in comments
>>
>>
>> // Robert
>>
>> On 12/06/2016 04:55 PM, Robert Yang wrote:
>>
>>> * V2
>>>   - Add QB_NETWORK_DEVICE to set network device for both slirp and tap,
>>> the idea is from Randy and Nathan.
>>>   - Use different mac sections for slirp and tap to fix conflicts when
>>> running both of them on the same host.
>>>
>>> * V1
>>>   - Initial version
>>>
>>> The following changes since commit 11063a01d4511b2688ea7ba2d7359e
>>> 4e07328c66:
>>>
>>>   ruby: upgrade to 2.3.1 (2016-11-30 15:47:17 +)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.openembedded.org/openembedded-core-contrib rbt/runqemu
>>>
>>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-cont
>>> rib/log/?h=rbt/runqemu
>>>
>>>
>>> Robert Yang (6):
>>>   scripts/runqemu: fix checking for .cpio.gz
>>>   qemuboot.bbclass: use IMGDEPLOYDIR
>>>   runqemu-export-rootfs: fix inconsistent var names
>>>   runqemu: support mutiple qemus running when nfs
>>>   runqemu: fixes for slirp, network device and hostfwd
>>>   qemuboot.bbclass: add blank lines in comments
>>>
>>>  meta/classes/qemuboot.bbclass  |  34 ++--
>>>  meta/conf/machine/include/qemuboot-x86.inc |   1 -
>>>  meta/conf/machine/qemuarm64.conf   |   1 -
>>>  scripts/runqemu| 133
>>> ++---
>>>  scripts/runqemu-export-rootfs  |  21 ++---
>>>  5 files changed, 140 insertions(+), 50 deletions(-)
>>>
>>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] busybox: update flock behavior to match upstream

[Phil Blundell]

On Thu, 2016-04-21 at 12:24 +0300, Maxin B. John wrote:
> 
+-
> +-if (argv[0])
> +-return spawn_and_wait(argv);
> +-
> ++if (argv[0]) {
> ++cmd_args[0] = getenv("SHELL");
> ++if (!cmd_args[0])
> ++cmd_args[0] = (char*)DEFAULT_SHELL;
> ++cmd_args[1] = (char*)"-c";
> ++cmd_args[2] = argv[0];
> ++cmd_args[3] = NULL;
> ++return spawn_and_wait(cmd_args);
> ++}
> + return EXIT_SUCCESS;
> + }
> 

This patch seems to completely break the behaviour of flock when
invoked without "-c".  For example, compare the behaviour of:

flock /tmp/lock echo it works

before and after.  Please revert this patch until and unless it can be
fixed.

p.

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

Re: [OE-core] [PATCHv2] qemu: Upgrade to 2.8.0

[Burton, Ross]

On 17 January 2017 at 12:04, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> If this isn't fixed in reasonable time, we should probably disable qemu
> usermode on ppc - unfortunate, but that's the deal with using it for
> anything.
>

I consider that a backup position, stalling the upgrade to see if upstream
can fix it is preferable.

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

Re: [OE-core] [PATCHv2] qemu: Upgrade to 2.8.0

[Alexander Kanavin]

On 01/16/2017 11:42 PM, Aníbal Limón wrote:


(gdb) info threds
  Id   Target Id Frame
  1Thread 0x77fd0780 (LWP 25006) "qemu-ppc"
pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  2Thread 0x7647e700 (LWP 25010) "qemu-ppc" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
* 3Thread 0x77f4d700 (LWP 25011) "qemu-ppc" 0x0086e204
in static_code_gen_buffer ()

I'll send an email to the qemu mailing list.


If this isn't fixed in reasonable time, we should probably disable qemu 
usermode on ppc - unfortunate, but that's the deal with using it for 
anything.


You would need to just copy/tweak the corresponding line from 
meta/conf/machine/include/powerpc/arch-powerpc64.inc


Alex

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

Re: [OE-core] [PATCH v7] rootfs: Modify RPM installation

[David Vincent]

On lundi 16 janvier 2017 17:39:45 CET Burton, Ross wrote:
> On 12 January 2017 at 09:08, David Vincent  wrote:
> > When using a custom RPM data directory instead of the default dir
> > '/var/lib/rpm', the final image did not contain any of the database
> > files in the expected location. This commit takes into account the
> > 'rpmlibdir' variable set into 'rootfs_rpm.bbclass'.
> 
> Something changed and this is now breaking rootfs generation for me:

It becomes weirder and weirder...

> 
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:license_create_manifest(d)
>  0003:
> File:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/meta/cl
> asses/license.bbclass', lineno: 48, function: license_create_manifest
>  0044:pkg_dic = {}
>  0045:for pkg in sorted(image_list_installed_packages(d)):
>  0046:pkg_info = os.path.join(d.getVar('PKGDATA_DIR'),
>  0047:'runtime-reverse', pkg)
>  *** 0048:pkg_name = os.path.basename(os.readlink(pkg_info))
>  0049:
>  0050:pkg_dic[pkg_name] =
> oe.packagedata.read_pkgdatafile(pkg_info)
>  0051:if not "LICENSE" in pkg_dic[pkg_name].keys():
>  0052:pkg_lic_name = "LICENSE_" + pkg_name
> Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/t
> mp/sysroots/qemux86-64/pkgdata/runtime-reverse/error:'
> 
> Note how pkg is set to "error:".

I found that the RpmPkgsList is also using 'rpmlibdir'. Could it be possible 
that it must be defined for class-native and class-target ? Therefore, maybe 
setting a default value in each case could solve the problem ?
I'm using this patch on a daily basis and I don't have problems but, in my 
case, I set a default value for rpmlibdir at the distro level which I override 
for class-target in some of my BSP layers.

I can fall back to v6 and set a default value using a weak assignment for 
rpmlibdir.

> 
> Clearly the error handling in image_list_installed_packages() needs work,
> but I can make this problem appear/disappear by adding/removing this patch.
> 
> Ross

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