date:20141103

On 3 November 2014 09:17, Yi Qingliang niqingliang2...@gmail.com wrote:

 I have removed 'x11' in 'DISTRO_FEATURE', I don't know if it is the reason.


That's the reason.  libGL.so is GLX, and the X in GLX means X11.

If you're building something that wants to use OpenGL without X11, then you
need to use EGL.

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

Re: [OE-core] Weird ALTERNATIVES and staging conflict.


On 10/30/2014 06:47 PM, Richard Purdie wrote:

On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:

I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc

Now you can have multiple recipes using it, and as such, it seemed a good idea
to add these lines to that recipe:

+ALTERNATIVE_${PN} = fpga.bin bitstreams
+ALTERNATIVE_LINK_NAME[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_TARGET[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_LINK_NAME[bitstreams] = ${datadir}/bitstreams
+ALTERNATIVE_TARGET[bitstreams] = ${datadir}/bitstreams


This still resulted in staging conflicts.


This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.


I don't want these files in sysroot, I want them on target only.


But looking at the contents of the fake packages, the fpga.bin has been
renamed by alternatives (as expected), and the symlink will be created after
installing, so how come I still get this?


The staging code uses the output of do_install directly and does
different things to the packaging code path. We've never had someone
with this problem before. Binaries in *bindir only get installed into
the sysroot in the -native case.

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.


If I understand you correctly, the problem is that the recipe is trying to 
install things in sysroot?




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

ping

 Op 22 sep. 2014, om 14:12 heeft Koen Kooi koen.k...@linaro.org het volgende 
 geschreven:
 
 The configure override was too restrictive, it needed both 'arm' and 'neon' 
 to trigger, which breaks on aarch64. Since TUNE_FEATURES is the only 
 qualifier that matters, drop the 'arm' override.
 
 Buildtested for 'genericarmv8' and 'qemux86' machines.
 
 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
 meta/recipes-multimedia/libpng/libpng_1.6.13.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.13.bb 
 b/meta/recipes-multimedia/libpng/libpng_1.6.13.bb
 index 0c6fd1f..8798a96 100644
 --- a/meta/recipes-multimedia/libpng/libpng_1.6.13.bb
 +++ b/meta/recipes-multimedia/libpng/libpng_1.6.13.bb
 @@ -19,7 +19,7 @@ BINCONFIG = ${bindir}/libpng-config 
 ${bindir}/libpng16-config
 inherit autotools binconfig-disabled pkgconfig
 
 # Work around missing symbols
 -EXTRA_OECONF_append_arm =  ${@bb.utils.contains(TUNE_FEATURES, neon, 
 --enable-arm-neon=on, --enable-arm-neon=off ,d)}
 +EXTRA_OECONF_append =  ${@bb.utils.contains(TUNE_FEATURES, neon, 
 --enable-arm-neon=on, --enable-arm-neon=off ,d)}
 
 PACKAGES =+ ${PN}-tools
 
 -- 
 1.9.3
 

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

Re: [OE-core] [PATCH 1/1] systemd: add network config while networkd supported


 Op 3 nov. 2014, om 08:37 heeft Hongxu Jia hongxu@windriver.com het 
 volgende geschreven:
 
 While networkd supported, we add network config which starts
 dhcp by default.
 
 And the customers could edit it according their own requirements.
 (dhcp or static ip...)
 
 It refers:
 https://wiki.archlinux.org/index.php/systemd-networkd
 
 Signed-off-by: Hongxu Jia hongxu@windriver.com
 ---
 meta/recipes-core/systemd/systemd/oe-core.network | 8 
 meta/recipes-core/systemd/systemd_216.bb  | 6 ++
 2 files changed, 14 insertions(+)
 create mode 100644 meta/recipes-core/systemd/systemd/oe-core.network
 
 diff --git a/meta/recipes-core/systemd/systemd/oe-core.network 
 b/meta/recipes-core/systemd/systemd/oe-core.network
 new file mode 100644
 index 000..fcaefc2
 --- /dev/null
 +++ b/meta/recipes-core/systemd/systemd/oe-core.network

First: config files on the target shouldn't be named after the buildsystem, a 
better name would be 'ethernet.network' or something similar

 @@ -0,0 +1,8 @@
 +[Match]
 +Name=eth*

Add 'en*' as well for pci devices that get renamed by udev

 +[Network]
 +DHCP=v4

DHCP=both or DHCP=yes would be better since that would include dhcpv6 as well

 +[DHCPv4]
 +UseHostname=false

Why? Using the hostname makes DHCP logs a lot easier to debug.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Weird ALTERNATIVES and staging conflict.

On Mon, 2014-11-03 at 10:53 +0100, Mike Looijmans wrote:
On 10/30/2014 06:47 PM, Richard Purdie wrote:
On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:
I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc

Now you can have multiple recipes using it, and as such, it seemed a good
idea
to add these lines to that recipe:

+ALTERNATIVE_${PN} = fpga.bin bitstreams
+ALTERNATIVE_LINK_NAME[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_TARGET[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_LINK_NAME[bitstreams] = ${datadir}/bitstreams
+ALTERNATIVE_TARGET[bitstreams] = ${datadir}/bitstreams

This still resulted in staging conflicts.

This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.

I don't want these files in sysroot, I want them on target only.

Ok, that makes things much easier.

But looking at the contents of the fake packages, the fpga.bin has been
renamed by alternatives (as expected), and the symlink will be created
after
installing, so how come I still get this?

The staging code uses the output of do_install directly and does
different things to the packaging code path. We've never had someone
with this problem before. Binaries in *bindir only get installed into
the sysroot in the -native case.

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.

If I understand you correctly, the problem is that the recipe is trying to
install things in sysroot?

Correct, by default ${datadir} is staged. The easiest way to handle this
may be to define your own sysroot_stage_all function (or
sysroot_stage_dirs) which just stages what you need, if anything.

Cheers,

Richard

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

Re: [OE-core] [PATCH 1/1] systemd: add network config while networkd supported


 Op 3 nov. 2014, om 08:37 heeft Hongxu Jia hongxu@windriver.com het 
 volgende geschreven:
 
 While networkd supported, we add network config which starts
 dhcp by default.
 
 And the customers could edit it according their own requirements.
 (dhcp or static ip...)

Another thing: don't put this in the main systemd recipe, forcing layers to 
bbappend systemd_git.bb for only a networking config file is hazardous and too 
invasive due to sstate invalidation. I don't want to be forced to rebuild Xorg 
and flood people with updated packages in the feeds because I, or worse, some 
random layer wants to change the default network settings.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] debianutils: Add recipe from meta-oe

2014-11-03 Thread Ricardo Ribalda Delgado

This recipe is a running dependency of recipe apt

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
 .../recipes-support/debianutils/debianutils_4.4.bb | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 meta/recipes-support/debianutils/debianutils_4.4.bb

diff --git a/meta/recipes-support/debianutils/debianutils_4.4.bb 
b/meta/recipes-support/debianutils/debianutils_4.4.bb
new file mode 100644
index 000..346eaf1
--- /dev/null
+++ b/meta/recipes-support/debianutils/debianutils_4.4.bb
@@ -0,0 +1,35 @@
+SUMMARY = Miscellaneous utilities specific to Debian
+SECTION = base
+LICENSE = GPLv2  SMAIL_GPL
+LIC_FILES_CHKSUM = 
file://debian/copyright;md5=f01a5203d50512fc4830b4332b696a9f
+
+SRC_URI = ${DEBIAN_MIRROR}/main/d/${BPN}/${BPN}_${PV}.tar.gz
+SRC_URI[md5sum] = c0cb076754d7f4eb1e3397d00916647f
+SRC_URI[sha256sum] = 
190850cdd6b5302e0a1ba1aaed1bc7074d67d3bd8d04c613f242f7145afa53a6
+
+inherit autotools update-alternatives
+
+do_configure_prepend() {
+sed -i -e 's:tempfile.1 which.1:which.1:g' ${S}/Makefile.am
+}
+
+do_install_append() {
+if [ ${base_bindir} != ${bindir} ]; then
+# Debian places some utils into ${base_bindir} as does busybox
+install -d ${D}${base_bindir}
+for app in run-parts tempfile; do
+mv ${D}${bindir}/$app ${D}${base_bindir}/$app
+done
+fi
+}
+
+ALTERNATIVE_PRIORITY=100
+ALTERNATIVE_${PN} = add-shell installkernel remove-shell run-parts savelog 
tempfile which
+
+ALTERNATIVE_LINK_NAME[add-shell]=${sbindir}/add-shell
+ALTERNATIVE_LINK_NAME[installkernel]=${sbindir}/installkernel
+ALTERNATIVE_LINK_NAME[remove-shell]=${sbindir}/remove-shell
+ALTERNATIVE_LINK_NAME[run-parts]=${base_bindir}/run-parts
+ALTERNATIVE_LINK_NAME[savelog]=${bindir}/savelog
+ALTERNATIVE_LINK_NAME[tempfile]=${base_bindir}/tempfile
+ALTERNATIVE_LINK_NAME[which]=${bindir}/which
-- 
2.1.1

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

Re: [OE-core] [PATCH 0/1] systemd: add network config while networkd supported

2014-11-03 Thread Iorga, Cristian

Hi,

In my opinion, in the actual form, this patch cannot be taken in.
Reasons/questions:
1. How exactly this has been tested? I don't see any details. Testing network 
configs and doing modifications of this kind are sensible matters.
2. Different images have different ways of setting up network; for example, 
core-image-sato will manage network setup using conmman; has this configuration 
been tested?
3. How exactly is decided if networkd is active or not in a systemd-based Linux 
image?
4. Please go into details why exactly this patch has been submitted (what it 
tries to solve in the first place).

Regards,
Cristian

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Hongxu 
Jia
Sent: Monday, November 3, 2014 9:38 AM
To: openembedded-core@lists.openembedded.org; Burton, Ross; Chen, Qi (Wind 
River)
Subject: [OE-core] [PATCH 0/1] systemd: add network config while networkd 
supported

The following changes since commit f19b4e995ea47f9243f152b39337330307453c9f:

  bitbake: bitbake: clarify startup message (2014-10-30 13:39:52 +)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib hongxu/fix-systemd-network
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-systemd-network

Hongxu Jia (1):
  systemd: add network config while networkd supported

 meta/recipes-core/systemd/systemd/oe-core.network | 8 
 meta/recipes-core/systemd/systemd_216.bb  | 6 ++
 2 files changed, 14 insertions(+)
 create mode 100644 meta/recipes-core/systemd/systemd/oe-core.network

-- 
1.9.1

-- 
___
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 2/2] apt: Add missing running depency debianutils

2014-11-03 Thread Ricardo Ribalda Delgado

apt-file calls run-parts with options --list and --regex:

root@neopili:~/curro/qtec/qt5022/build-qt5022-cesium/build/tmp/work/bobcat_64-poky-linux/apt/0.9.9.4-r0/apt-0.9.9.4#
 grep run-parts cmdline/apt-key -rn
187:for trusted in $(run-parts --list $TRUSTEDPARTS --regex 
'^.*\.gpg$'); do

busybox implementation of run-parts does not support --regex. And --list option 
is not enabled on yocto busybox configuration.

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
 meta/recipes-devtools/apt/apt_0.9.9.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/apt/apt_0.9.9.4.bb 
b/meta/recipes-devtools/apt/apt_0.9.9.4.bb
index 86ffe66..77cbff1 100644
--- a/meta/recipes-devtools/apt/apt_0.9.9.4.bb
+++ b/meta/recipes-devtools/apt/apt_0.9.9.4.bb
@@ -1,5 +1,5 @@
 DEPENDS = curl db
-RDEPENDS_${PN} = dpkg bash
+RDEPENDS_${PN} = dpkg bash debianutils
 LIC_FILES_CHKSUM = file://COPYING.GPL;md5=0636e73ff0215e8d672dc4c32c317bb3
 require apt.inc
 
-- 
2.1.1

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

[OE-core] [PATCH 0/2] Add missing running depency of apt-key

2014-11-03 Thread Ricardo Ribalda Delgado

apt-file calls run-parts with options --list and --regex

root@neopili:~/curro/qtec/qt5022/build-qt5022-cesium/build/tmp/work/bobcat_64-poky-linux/apt/0.9.9.4-r0/apt-0.9.9.4#
 grep run-parts cmdline/apt-key -rn 
187:for trusted in $(run-parts --list $TRUSTEDPARTS --regex 
'^.*\.gpg$'); do


busybox implementation of run-parts does not support --regex. And --list option 
is not enabled on yocto busybox configuration.

Adding recipe debianutils from meta-oe fixes the issue.

This fixes bug #6924

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6924

Ricardo Ribalda Delgado (2):
  debianutils: Add recipe from meta-oe
  apt: Add missing running depency debianutils

 meta/recipes-devtools/apt/apt_0.9.9.4.bb   |  2 +-
 .../recipes-support/debianutils/debianutils_4.4.bb | 35 ++
 2 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/debianutils/debianutils_4.4.bb

-- 
2.1.1

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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

On 3 November 2014 09:57, Koen Kooi k...@dominion.thruhere.net wrote:

 ping


Last night I was looking at my post-1.7 tag and the number of aarch64
patches there.   Kai, did you continue work on that staging branch for all
of the aarch64 patches that were being posted?

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

[OE-core] [PATCH 1/1] toaster.bbclass: read elapsed time from the stats file

2014-11-03 Thread Alex DAMIAN

From: Alexandru DAMIAN alexandru.dam...@intel.com

We read the elapsed time fromt the build stats file, instead
of computing it independently.

[YOCTO #6833]
[YOCTO #6685]

Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
---
 meta/classes/toaster.bbclass | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/meta/classes/toaster.bbclass b/meta/classes/toaster.bbclass
index 95499a5..1525317 100644
--- a/meta/classes/toaster.bbclass
+++ b/meta/classes/toaster.bbclass
@@ -187,8 +187,10 @@ python toaster_collect_task_stats() {
 def _read_stats(filename):
 cpu_usage = 0
 disk_io = 0
-startio = ''
-endio = ''
+startio = '0'
+endio = '0'
+started = '0'
+ended = '0'
 pn = ''
 taskname = ''
 statinfo = {}
@@ -198,20 +200,28 @@ python toaster_collect_task_stats() {
 k,v = line.strip().split(: , 1)
 statinfo[k] = v
 
-try:
-cpu_usage = statinfo[CPU usage]
-endio = statinfo[EndTimeIO]
-startio = statinfo[StartTimeIO]
-except KeyError:
-pass# we may have incomplete data here
+if CPU usage in statinfo:
+cpu_usage = str(statinfo[CPU usage]).strip('% \n\r')
 
-if startio and endio:
-disk_io = int(endio.strip('\n ')) - int(startio.strip('\n '))
+if EndTimeIO in statinfo:
+endio = str(statinfo[EndTimeIO]).strip('% \n\r')
 
-if cpu_usage:
-cpu_usage = float(cpu_usage.strip('% \n'))
+if StartTimeIO in statinfo:
+startio = str(statinfo[StartTimeIO]).strip('% \n\r')
 
-return {'cpu_usage': cpu_usage, 'disk_io': disk_io}
+if Started in statinfo:
+started = str(statinfo[Started]).strip('% \n\r')
+
+if Ended in statinfo:
+ended = str(statinfo[Ended]).strip('% \n\r')
+
+disk_io = int(endio) - int(startio)
+
+elapsed_time = float(ended) - float(started)
+
+cpu_usage = float(cpu_usage)
+
+return {'cpu_usage': cpu_usage, 'disk_io': disk_io, 'elapsed_time': 
elapsed_time}
 
 
 if isinstance(e, (bb.build.TaskSucceeded, bb.build.TaskFailed)):
-- 
1.9.1

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

Re: [OE-core] Weird ALTERNATIVES and staging conflict.


On 11/03/2014 11:04 AM, Richard Purdie wrote:

On Mon, 2014-11-03 at 10:53 +0100, Mike Looijmans wrote:

On 10/30/2014 06:47 PM, Richard Purdie wrote:

On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:

I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc

Now you can have multiple recipes using it, and as such, it seemed a good idea
to add these lines to that recipe:

+ALTERNATIVE_${PN} = fpga.bin bitstreams
+ALTERNATIVE_LINK_NAME[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_TARGET[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_LINK_NAME[bitstreams] = ${datadir}/bitstreams
+ALTERNATIVE_TARGET[bitstreams] = ${datadir}/bitstreams


This still resulted in staging conflicts.


This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.


I don't want these files in sysroot, I want them on target only.


Ok, that makes things much easier.


But looking at the contents of the fake packages, the fpga.bin has been
renamed by alternatives (as expected), and the symlink will be created after
installing, so how come I still get this?


The staging code uses the output of do_install directly and does
different things to the packaging code path. We've never had someone
with this problem before. Binaries in *bindir only get installed into
the sysroot in the -native case.

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.


If I understand you correctly, the problem is that the recipe is trying to
install things in sysroot?


Correct, by default ${datadir} is staged. The easiest way to handle this
may be to define your own sysroot_stage_all function (or
sysroot_stage_dirs) which just stages what you need, if anything.


In other words, make  sysroot_stage_all into a no-op?

I've been looking at the staging.bbclass, but that's basically the best I can 
come up with.


M.


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64


 Op 3 nov. 2014, om 11:25 heeft Burton, Ross ross.bur...@intel.com het 
 volgende geschreven:
 
 On 3 November 2014 09:57, Koen Kooi k...@dominion.thruhere.net wrote:
 ping
 
 Last night I was looking at my post-1.7 tag and the number of aarch64 
 patches there.   Kai, did you continue work on that staging branch for all of 
 the aarch64 patches that were being posted?

What does that have to do with this patch?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

On 3 November 2014 11:27, Koen Kooi k...@dominion.thruhere.net wrote:

  Last night I was looking at my post-1.7 tag and the number of aarch64
 patches there.   Kai, did you continue work on that staging branch for all
 of the aarch64 patches that were being posted?

 What does that have to do with this patch?


Kai was collecting patches that were sent to oe-core, and this may have
been one of them.

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

Re: [OE-core] Weird ALTERNATIVES and staging conflict.


On 11/03/2014 11:49 AM, Mike Looijmans wrote:

On 11/03/2014 11:04 AM, Richard Purdie wrote:

On Mon, 2014-11-03 at 10:53 +0100, Mike Looijmans wrote:

On 10/30/2014 06:47 PM, Richard Purdie wrote:

On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:

I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc


Now you can have multiple recipes using it, and as such, it seemed a good
idea
to add these lines to that recipe:

+ALTERNATIVE_${PN} = fpga.bin bitstreams
+ALTERNATIVE_LINK_NAME[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_TARGET[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_LINK_NAME[bitstreams] = ${datadir}/bitstreams
+ALTERNATIVE_TARGET[bitstreams] = ${datadir}/bitstreams


This still resulted in staging conflicts.


This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.


I don't want these files in sysroot, I want them on target only.


Ok, that makes things much easier.


But looking at the contents of the fake packages, the fpga.bin has been
renamed by alternatives (as expected), and the symlink will be created after
installing, so how come I still get this?


The staging code uses the output of do_install directly and does
different things to the packaging code path. We've never had someone
with this problem before. Binaries in *bindir only get installed into
the sysroot in the -native case.

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.


If I understand you correctly, the problem is that the recipe is trying to
install things in sysroot?


Correct, by default ${datadir} is staged. The easiest way to handle this
may be to define your own sysroot_stage_all function (or
sysroot_stage_dirs) which just stages what you need, if anything.


In other words, make  sysroot_stage_all into a no-op?

I've been looking at the staging.bbclass, but that's basically the best I can
come up with.


Ah, slightly better:

# Prevent bitstreams ending up in sysroot.
sysroot_stage_dirs_append() {
rm -rf $to${datadir}/fpga.bin $to${datadir}/bitstreams
}

This wastes a bit (installing multimegabyte bitstreams only to remove them) 
but it won't interfere with recipes that do wish to install things in sysroot.


I've tested with this now, and this appears to do exactly as I wanted.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [OE-core] Weird ALTERNATIVES and staging conflict.

On Mon, 2014-11-03 at 11:49 +0100, Mike Looijmans wrote:
On 11/03/2014 11:04 AM, Richard Purdie wrote:
On Mon, 2014-11-03 at 10:53 +0100, Mike Looijmans wrote:
On 10/30/2014 06:47 PM, Richard Purdie wrote:
On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:
I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc

Now you can have multiple recipes using it, and as such, it seemed a
good idea
to add these lines to that recipe:

This still resulted in staging conflicts.

This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.

I don't want these files in sysroot, I want them on target only.

Ok, that makes things much easier.

But looking at the contents of the fake packages, the fpga.bin has been
renamed by alternatives (as expected), and the symlink will be created
after
installing, so how come I still get this?

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.

If I understand you correctly, the problem is that the recipe is trying to
install things in sysroot?

Correct, by default ${datadir} is staged. The easiest way to handle this
may be to define your own sysroot_stage_all function (or
sysroot_stage_dirs) which just stages what you need, if anything.

In other words, make sysroot_stage_all into a no-op?

I've been looking at the staging.bbclass, but that's basically the best I can
come up with.

I don't know what else your recipe may need. If you don't need to stage
anything into the sysroots, make it a no-op, yes.

Cheers,

Richard

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

Re: [OE-core] [PATCH] curl: Security Advisory - curl - CVE-2014-3620

On 3 November 2014 09:31, Chong Lu chong...@windriver.com wrote:

  meta/recipes-support/curl/curl/CVE-2014-3620.patch |   69
 


ERROR: Command Error: exit status: 1  Output:
Applying patch CVE-2014-3620.patch
patching file lib/cookie.c
patching file tests/data/test61
Hunk #1 FAILED at 21.

Assuming that this is a line ending problem again, do you have this commit
in a git repository somewhere?

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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64


 Op 3 nov. 2014, om 12:30 heeft Burton, Ross ross.bur...@intel.com het 
 volgende geschreven:
 
 
 On 3 November 2014 11:27, Koen Kooi k...@dominion.thruhere.net wrote:
  Last night I was looking at my post-1.7 tag and the number of aarch64 
  patches there.   Kai, did you continue work on that staging branch for all 
  of the aarch64 patches that were being posted?
 
 What does that have to do with this patch?
 
 Kai was collecting patches that were sent to oe-core, and this may have been 
 one of them.

Is this some new requirement for OE-core patches?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Weird ALTERNATIVES and staging conflict.

On Mon, 2014-11-03 at 12:35 +0100, Mike Looijmans wrote:
On 11/03/2014 11:49 AM, Mike Looijmans wrote:
On 11/03/2014 11:04 AM, Richard Purdie wrote:
On Mon, 2014-11-03 at 10:53 +0100, Mike Looijmans wrote:
On 10/30/2014 06:47 PM, Richard Purdie wrote:
On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:
I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc

Now you can have multiple recipes using it, and as such, it seemed a
good
idea
to add these lines to that recipe:

This still resulted in staging conflicts.

This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.

I don't want these files in sysroot, I want them on target only.

Ok, that makes things much easier.

But looking at the contents of the fake packages, the fpga.bin has been
renamed by alternatives (as expected), and the symlink will be created
after
installing, so how come I still get this?

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.

If I understand you correctly, the problem is that the recipe is trying to
install things in sysroot?

Correct, by default ${datadir} is staged. The easiest way to handle this
may be to define your own sysroot_stage_all function (or
sysroot_stage_dirs) which just stages what you need, if anything.

In other words, make sysroot_stage_all into a no-op?

I've been looking at the staging.bbclass, but that's basically the best I
can
come up with.

Ah, slightly better:

# Prevent bitstreams ending up in sysroot.
sysroot_stage_dirs_append() {
rm -rf $to${datadir}/fpga.bin $to${datadir}/bitstreams
}

This wastes a bit (installing multimegabyte bitstreams only to remove them)
but it won't interfere with recipes that do wish to install things in sysroot.

I've tested with this now, and this appears to do exactly as I wanted.

That is fine and perfectly acceptable. Just to be clear, you can also
do:

sysroot_stage_all() {
:
}

in your recipe and it will only affect that recipe, not all recipes.

Cheers,

Richard

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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

2014-11-03 Thread Carr, Chris (GE Intelligent Platforms)

On Mon, 2014-11-03 at 13:06 +0100, Koen Kooi wrote:
  Op 3 nov. 2014, om 12:30 heeft Burton, Ross ross.bur...@intel.com het 
  volgende geschreven:
  
  
  On 3 November 2014 11:27, Koen Kooi k...@dominion.thruhere.net wrote:
   Last night I was looking at my post-1.7 tag and the number of aarch64 
   patches there.   Kai, did you continue work on that staging branch for 
   all of the aarch64 patches that were being posted?
  
  What does that have to do with this patch?
  
  Kai was collecting patches that were sent to oe-core, and this may have 
  been one of them.
 
 Is this some new requirement for OE-core patches?

Its someone being helpful and trying to consolidate a topic branch and
test things before it gets merged.

So its not a new requirement but it is helpful and appreciated.

Cheers,

Richard

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

Re: [OE-core] [PATCH] package_manager: Fix BAD_RECOMMENDATIONS for opkg

On 26/10/2014 19:37, Paul Barker wrote:
 On 26 October 2014 19:36, Paul Barker p...@paulbarker.me.uk wrote:
 In package_manager.py, when using opkg as the packager, the command 'opkg 
 args
 info pkg' is called to get information about each pkg in 
 BAD_RECOMMENDATIONS
 in a format that can be written to the status file. The 'Status: ...' line is
 modified and all other lines are passed through. Changing the verbosity level
 argument for this command will change what it written into the status file.
 Crucially, with the default verbosity level, no blank lines are being 
 printed by
 the opkg command and so no blank lines are being written to the status file 
 to
 separate each package entry.

 The package parsing code in opkg expects package entries in the status file 
 to
 be separated by at least one blank line. If no blank line is seen, the next
 package entry is interpreted as a continuation of the last package entry, but
 the new values overwrite the old values.

 So with the default verbosity level, a blank line follows some package 
 entries
 and these are parsed. The others are dropped due to the lack of blank lines. 
 As
 the verbosity increases, more debugging messages add blank lines and more
 packages are parsed.

 The solution to ensure that this works correctly regardless of the verbosity
 level is simply add a blank line after the output of 'opkg info' is written 
 to
 the status file, ensuring that the next package is separated from the current
 package.

 [YOCTO #6816]

 Signed-off-by: Paul Barker p...@paulbarker.me.uk
 Cc: Chris Carr chris.c...@ge.com
 ---
  meta/lib/oe/package_manager.py | 4 
  1 file changed, 4 insertions(+)

 diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
 index ffb83b2..85d7fd4 100644
 --- a/meta/lib/oe/package_manager.py
 +++ b/meta/lib/oe/package_manager.py
 @@ -1408,6 +1408,10 @@ class OpkgPM(PackageManager):
  else:
  status.write(line + \n)

 +# Append a blank line after each package entry to ensure 
 that it
 +# is separated from the following entry
 +status.write(\n)
 +
  '''
  The following function dummy installs pkgs and returns the log of 
 output.
  '''
 --
 2.1.2

 
 Chris, could you give this a test and let us know if it fixes the issue.
 
 Thanks,
 

Paul,

I've tried the patch with my build and all the packages in BAD_RECOMMENDATIONS 
are now being processed correctly and do not appear in the target rootfs.

[My subscription to the OE Core mailing list had quietly expired, so I've 
re-subscribed to ensure that this reply goes to the list as well]

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

Re: [OE-core] [PATCH v2] shadow: enable support for subordinate IDs

2014-11-03 Thread bogdan.purcare...@freescale.com

Hello,

Can someone kindly review my patch? I haven't sent patches to this list yet and 
I don't know who the maintainer is.

Please let me know if there's anything else I can do in order to have this fix 
merged.

Thank you,
Bogdan P.

 -Original Message-
 From: Bogdan Purcareata [mailto:bogdan.purcare...@freescale.com]
 Sent: Monday, October 27, 2014 5:52 PM
 To: openembedded-core@lists.openembedded.org
 Cc: Purcareata Bogdan-B43198
 Subject: [PATCH v2] shadow: enable support for subordinate IDs
 
 The subordinate IDs support in pkg-shadow allows unprivileged users to manage
 a
 set of UIDs and GIDs. These subordinate IDs are specified by root, and can be
 further used by the unprivileged user they have been assigned to. This user
 can
 then create an e.g. user namespace, where he is allowed to manage his own set
 of
 users and group from the pool of subordinate IDs. More details can be found at
 http://lwn.net/Articles/533617/.
 
 Pull a required change from upstream in order to make shadow cross-compile
 with
 subordinate IDs support. Enable flag in recipe.
 
 Changes since v1:
 - update changelog
 
 Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com
 ---
  ..._of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patch |   41
 
  meta/recipes-extended/shadow/shadow.inc|3 +-
  2 files changed, 43 insertions(+), 1 deletion(-)
  create mode 100644 meta/recipes-
 extended/shadow/files/check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patc
 h
 
 diff --git a/meta/recipes-
 extended/shadow/files/check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patc
 h b/meta/recipes-
 extended/shadow/files/check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patc
 h
 new file mode 100644
 index 000..185590c
 --- /dev/null
 +++ b/meta/recipes-
 extended/shadow/files/check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patc
 h
 @@ -0,0 +1,41 @@
 +From 2cb54158b80cdbd97ca3b36df83f9255e923ae3f Mon Sep 17 00:00:00 2001
 +From: James Le Cuirot ch...@aura-online.co.uk
 +Date: Sat, 23 Aug 2014 09:46:39 +0100
 +Subject: [PATCH] Check size of uid_t and gid_t using AC_CHECK_SIZEOF
 +
 +This built-in check is simpler than the previous method and, most
 +importantly, works when cross-compiling.
 +
 +Upstream-Status: Accepted
 +[https://github.com/shadow-
 maint/shadow/commit/2cb54158b80cdbd97ca3b36df83f9255e923ae3f]
 +
 +Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
 +---
 + configure.in | 14 --
 + 1 file changed, 4 insertions(+), 10 deletions(-)
 +
 +diff --git a/configure.in b/configure.in
 +index 1a3f841..4a4d6d0 100644
 +--- a/configure.in
  b/configure.in
 +@@ -335,16 +335,10 @@ if test $enable_subids != no; then
 + dnl
 + dnl FIXME: check if 32 bit UIDs/GIDs are supported by libc
 + dnl
 +-AC_RUN_IFELSE([AC_LANG_SOURCE([
 +-#include sys/types.h
 +-int main(void) {
 +-uid_t u;
 +-gid_t g;
 +-return (sizeof u  4) || (sizeof g  4);
 +-}
 +-])], [id32bit=yes], [id32bit=no])
 +-
 +-if test x$id32bit = xyes; then
 ++AC_CHECK_SIZEOF([uid_t],, [#include sys/types.h])
 ++AC_CHECK_SIZEOF([gid_t],, [#include sys/types.h])
 ++
 ++if test $ac_cv_sizeof_uid_t -ge 4  test $ac_cv_sizeof_gid_t -ge 4;
 then
 + AC_DEFINE(ENABLE_SUBIDS, 1, [Define to support the subordinate
 IDs.])
 + enable_subids=yes
 + else
 diff --git a/meta/recipes-extended/shadow/shadow.inc b/meta/recipes-
 extended/shadow/shadow.inc
 index b2a5f0e..9fada0d 100644
 --- a/meta/recipes-extended/shadow/shadow.inc
 +++ b/meta/recipes-extended/shadow/shadow.inc
 @@ -16,6 +16,7 @@ SRC_URI = http://pkg-
 shadow.alioth.debian.org/releases/${BPN}-${PV}.tar.xz \
 file://fix-installation-failure-with-subids-disabled.patch \
 file://0001-su.c-fix-to-exec-command-correctly.patch \
 file://0001-Do-not-read-login.defs-before-doing-chroot.patch \
 +   file://check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patch \
 ${@bb.utils.contains('PACKAGECONFIG', 'pam', '${PAM_SRC_URI}', '',
 d)} \
 
 
 @@ -52,7 +53,7 @@ EXTRA_OECONF += --without-audit \
   --without-libcrack \
   --without-selinux \
   --with-group-name-max-length=24 \
 - --enable-subordinate-ids=no \
 + --enable-subordinate-ids=yes \
   ${NSCDOPT}
 
  NSCDOPT = 
 --
 1.7.10.4

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

Re: [OE-core] Weird ALTERNATIVES and staging conflict.


On 11/03/2014 01:09 PM, Richard Purdie wrote:

On Mon, 2014-11-03 at 12:35 +0100, Mike Looijmans wrote:

On 11/03/2014 11:49 AM, Mike Looijmans wrote:

On 11/03/2014 11:04 AM, Richard Purdie wrote:

On Mon, 2014-11-03 at 10:53 +0100, Mike Looijmans wrote:

On 10/30/2014 06:47 PM, Richard Purdie wrote:

On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:

I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc


Now you can have multiple recipes using it, and as such, it seemed a good
idea
to add these lines to that recipe:

+ALTERNATIVE_${PN} = fpga.bin bitstreams
+ALTERNATIVE_LINK_NAME[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_TARGET[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_LINK_NAME[bitstreams] = ${datadir}/bitstreams
+ALTERNATIVE_TARGET[bitstreams] = ${datadir}/bitstreams


This still resulted in staging conflicts.


This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.


I don't want these files in sysroot, I want them on target only.


Ok, that makes things much easier.


But looking at the contents of the fake packages, the fpga.bin has been
renamed by alternatives (as expected), and the symlink will be created after
installing, so how come I still get this?


The staging code uses the output of do_install directly and does
different things to the packaging code path. We've never had someone
with this problem before. Binaries in *bindir only get installed into
the sysroot in the -native case.

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.


If I understand you correctly, the problem is that the recipe is trying to
install things in sysroot?


Correct, by default ${datadir} is staged. The easiest way to handle this
may be to define your own sysroot_stage_all function (or
sysroot_stage_dirs) which just stages what you need, if anything.


In other words, make  sysroot_stage_all into a no-op?

I've been looking at the staging.bbclass, but that's basically the best I can
come up with.


Ah, slightly better:

# Prevent bitstreams ending up in sysroot.
sysroot_stage_dirs_append() {
rm -rf $to${datadir}/fpga.bin $to${datadir}/bitstreams
}

This wastes a bit (installing multimegabyte bitstreams only to remove them)
but it won't interfere with recipes that do wish to install things in sysroot.

I've tested with this now, and this appears to do exactly as I wanted.


That is fine and perfectly acceptable. Just to be clear, you can also
do:

sysroot_stage_all() {
:
}

in your recipe and it will only affect that recipe, not all recipes.


It's slowly growing into a more of a class. This particular file gets included 
by all FPGA image recipes (which is why I needed the alternatives mechanism), 
so in my particular case, any change here affects a dozen actual packages.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [OE-core] Request to move gitpkgv.bbclass from meta-oe to oe-core

I'm afraid this will go the same path as the previous attempt at getting 
gitpkgv equivalent into oe-core, which is, it'll silently disappear until 
someone with both the internal knowledge and the time to implement it will 
pick it up again...


M.

On 10/20/2014 04:00 PM, Mike Looijmans wrote:

On 10/10/2014 05:03 PM, Paul Eggleton wrote:

Hi Mike,

On Friday 10 October 2014 07:36:25 Mike Looijmans wrote:

On 10/10/2014 12:15 AM, Otavio Salvador wrote:

On Thu, Oct 9, 2014 at 4:56 PM, Richard Purdie

richard.pur...@linuxfoundation.org wrote:

On Thu, 2014-10-09 at 10:16 +0200, Mike Looijmans wrote:

In partial reply to my own question, this has been discussed 2 years
ago, but apparently nothing ever came out of it.

http://lists.openembedded.org/pipermail/openembedded-core/2012-February/
056050.html

So once more the request to be able to get sane version strings for git
repos. Can we please just move gitpkgv. That's like five minutes work,
and if anyone (e.g. me) feels like building something better, he or she
is free do submit that and get rid of the gitpkgv class once it's
obsolete.


I do feel quite strongly that this is something which should get
improved in the fetcher itself. That is why I've pushed back on the
patch since if I take it into OE-Core, there is even less incentive to
fix the real problem...


Mike I am also an user of gitpkgv but I must to agree with Richard
here. Moving this to OE-Core will just make it worse. It is way better
to prepare a patch and add support for it on the fetcher code of
BitBake.


Give me some pointers on what you're talking about here, and I'll be happy
to try and implement it. Currently I have no idea as to what is wrong
with the gitpkgv approach, and I also have no clue as to what it is you
want to have implemented in the git fetcher.


The code would go into the fetcher itself i.e. lib/bb/fetch2/git.py and
lib/bb/fetch2/__init__.py.

I'm not sure whether it would be a case of setting a variable in order to have
the value of SRCPV within OE (which calls bb.fetch2.get_srcrev() ) return the
git describe style version instead of the current one, or whether we would
preserve the separate GITPKGVTAG variable for that purpose. (The GITPKGV case
is already handled by the current behaviour of SRCPV, right?)

FWIW there is an open bug covering this issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2872


I followed that link a few clicks deeper and noticed that Richard Purdie
suggested adding another interface method, but I couldn't quite understand
what he meant here.


I figured that sortable_revision was the method that I needed to delve into.
However, it turned out that this one is called about 50 times when building a
single package, and i cannot really run any git commands at that spot it
seems, the current directory is not inside the repo.

So that's a fail (my trial code from git.py with some extra logger output 
below).



 def sortable_revision(self, ud, d, name):
 
 Return a sortable revision number by counting commits in the history
 
 rev = self._build_revision(ud, d, name)
 logger.warn(git.sortable_revision url=%s % (ud.url))
 localpath = ud.localpath
 rev_file = os.path.join(localpath, oe-gitpkgv_ + rev)
 if not os.path.exists(localpath):
 logger.warn(git.sortable_revision non-existent: %s % (localpath))
 commits = None
 else:
 if not os.path.exists(rev_file) or not os.path.getsize(rev_file):
 from pipes import quote
 commits = bb.fetch2.runfetchcmd(
 git rev-list %s -- 2 /dev/null | wc -l %
(quote(rev)),
 d, quiet=True).strip().lstrip('0')
 if commits:
 os.unlink(rev_file)
 open(rev_file, w).write(%d\n % int(commits))
 else:
 commits = open(rev_file, r).readline(128).strip()
 logger.warn(git.sortable_revision commits=%s\n % (commits))
 if commits:
 return False, %s+%s % (commits, rev[:7])
 else:
 return True, str(rev)




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [OE-core] [PATCH 01/27] toaster: add toaster layer configuration file

2014-11-03 Thread Damian, Alexandru

Sorry for the mix-up, you're right.

I'll re-post to correct mail list.

Alex

On Tue, Oct 28, 2014 at 3:49 PM, Koen Kooi k...@dominion.thruhere.net
wrote:


  Op 28 okt. 2014, om 15:09 heeft Alex DAMIAN alexandru.dam...@intel.com
 het volgende geschreven:
 
  From: Alexandru DAMIAN alexandru.dam...@intel.com
 
  In managed mode, Toaster tries to discover layers
  that are being checked-out on disk.
 
  In base layers, the toasterconf.json file
  describes basic configuration file for builds based
  on that layer, like default configuration variable
  settings, toaster-compatible branches, and the
  layerindex URL where the base layer and
  compatible layers are listed.
 
  This patch adds toasterconf.json file to the oe core layer.
 
  Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
  ---
  meta/conf/toasterconf.json | 71
 ++
  1 file changed, 71 insertions(+)
  create mode 100644 meta/conf/toasterconf.json
 
  diff --git a/meta/conf/toasterconf.json b/meta/conf/toasterconf.json
  new file mode 100644
  index 000..cdc7564
  --- /dev/null
  +++ b/meta/conf/toasterconf.json
  @@ -0,0 +1,71 @@
  +{
  +config: {MACHINE: qemux86, DISTRO: poky},


 This seems to be very inappropriate for OE-core, maybe you meant to send
 it to meta-poky?




-- 
Alex Damian
Yocto Project
SSG / OTC
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] support numeric owner/group tar image format

2014-11-03 Thread Mark Hatle


On 11/2/14, 4:48 AM, Peter A. Bigot wrote:

A classic approach to building SD card images with varying rootfs sizes
is to create the filesystem and unpack a tar rootfs image onto it.  When
done outside pseudo the encoded user and group names from the tar file
are converted to identifiers using host files, which often result in
incorrect assignment for common names like messagebus and ntp.

A solution is to create the rootfs archive using the numeric values
obtained from the target /etc files under pseudo, rather than the
corresponding names.  This series provides this function as a new image
file format nug.tar.

Peter A. Bigot (2):
   image_types.bbclass: whitespace and reorder
   image_types.bbclass: add tar --numeric-owner support

  meta/classes/image_types.bbclass | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)



I think this is incorrect.

The current tar archives contain both the uname/gname -and- uid/gid.  When you 
extract, if you pass --numeric-owner it will switch from name to number.  (At 
least it has whenever I've done it.)  The default though is to use the uname/gname.


The issue with switching to uid/gid is that you can end up changing the default 
and you may enough end up dumping the name version.  This can cause security 
issues if you do partial extracts and there was some type of a mismatch between 
the original system and the one being extracted.  (Think field 
upgrade/debug/update cycle.)


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

Re: [OE-core] [PATCH 0/2] support numeric owner/group tar image format

2014-11-03 Thread Peter A. Bigot


On 11/03/2014 08:55 AM, Mark Hatle wrote:

On 11/2/14, 4:48 AM, Peter A. Bigot wrote:

A classic approach to building SD card images with varying rootfs sizes
is to create the filesystem and unpack a tar rootfs image onto it.  When
done outside pseudo the encoded user and group names from the tar file
are converted to identifiers using host files, which often result in
incorrect assignment for common names like messagebus and ntp.

A solution is to create the rootfs archive using the numeric values
obtained from the target /etc files under pseudo, rather than the
corresponding names.  This series provides this function as a new image
file format nug.tar.

Peter A. Bigot (2):
   image_types.bbclass: whitespace and reorder
   image_types.bbclass: add tar --numeric-owner support

  meta/classes/image_types.bbclass | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)



I think this is incorrect.

The current tar archives contain both the uname/gname -and- uid/gid.  
When you extract, if you pass --numeric-owner it will switch from name 
to number.  (At least it has whenever I've done it.)  The default 
though is to use the uname/gname.


You're correct; both are stored per: 
http://www.gnu.org/software/tar/manual/html_node/Standard.html


This should probably be publicized more widely, since when the issue 
came up recently I wasn't the only one who discovered the hand-generated 
images had the wrong uid/gid values for non-root files.  Unnecessarily, 
as it turns out: adding --numeric-owner to the unpack does solve the 
problem.


Thanks.  I'll archive both patches in patchwork (the first is still 
valid, but is now unmotivated).


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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64


Op 3 nov. 2014, om 13:10 heeft Richard Purdie 
richard.pur...@linuxfoundation.org het volgende geschreven:

 On Mon, 2014-11-03 at 13:06 +0100, Koen Kooi wrote:
 Op 3 nov. 2014, om 12:30 heeft Burton, Ross ross.bur...@intel.com het 
 volgende geschreven:
 
 
 On 3 November 2014 11:27, Koen Kooi k...@dominion.thruhere.net wrote:
 Last night I was looking at my post-1.7 tag and the number of aarch64 
 patches there.   Kai, did you continue work on that staging branch for all 
 of the aarch64 patches that were being posted?
 
 What does that have to do with this patch?
 
 Kai was collecting patches that were sent to oe-core, and this may have 
 been one of them.
 
 Is this some new requirement for OE-core patches?
 
 Its someone being helpful and trying to consolidate a topic branch and
 test things before it gets merged.
 
 So its not a new requirement but it is helpful and appreciated.

It's been over a month and libpng is still broken, so I refuse to classify this 
new process as 'helpful' or as 'appreciated' at this point. 

If this continues can the person doing such a branch reply to patches intended 
for it saying they will or won't be queued? And please run the patches without 
such a reply through the regular process. That would be both helpful and 
appreciated.

--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs



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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

On 3 November 2014 15:24, Koen Kooi koen.k...@linaro.org wrote:

 It's been over a month and libpng is still broken, so I refuse to classify
 this new process as 'helpful' or as 'appreciated' at this point.


Remember that 1.7 was frozen solid for several weeks of that month, so no
it wouldn't have been merged in that time period.  It's only just
re-opened: master is currently 80 patches ahead of dizzy, 35 in the C-Pull
I sent last night, and another 33 in my staging branch right now so it's
not like we're taking it easy right now.

Some context: during September it was obvious that various parties had an
interest in aarch64 (Linaro and Wind River).  Patches to fix build failures
were being sent sporadically, a qemuarm64 machine was submitted, but there
was no kernel for said machine to actually build.   At the time there was
no qemuarm64 machine that actually worked, so even merging the simple
fixes on just faith that they're correct would be reckless considering we
were freezing.  This is why I suggested[1] that someone with a vested
interest in aarch64 collate all the patches into a single branch and keep
it rebased to master so that when master opens, it can be tested on *all*
qemu architectures and merged.  It appears that this hasn't happened.  Will
Linaro be able to create a branch that incorporates all of the patches and
new machine that's been tested as a whole?

Ross

[1]
http://lists.openembedded.org/pipermail/openembedded-core/2014-September/097211.html
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

On Mon, 2014-11-03 at 16:24 +0100, Koen Kooi wrote:
 Op 3 nov. 2014, om 13:10 heeft Richard Purdie 
 richard.pur...@linuxfoundation.org het volgende geschreven:
 
  On Mon, 2014-11-03 at 13:06 +0100, Koen Kooi wrote:
  Op 3 nov. 2014, om 12:30 heeft Burton, Ross ross.bur...@intel.com het 
  volgende geschreven:
  
  
  On 3 November 2014 11:27, Koen Kooi k...@dominion.thruhere.net wrote:
  Last night I was looking at my post-1.7 tag and the number of aarch64 
  patches there.   Kai, did you continue work on that staging branch for 
  all of the aarch64 patches that were being posted?
  
  What does that have to do with this patch?
  
  Kai was collecting patches that were sent to oe-core, and this may have 
  been one of them.
  
  Is this some new requirement for OE-core patches?
  
  Its someone being helpful and trying to consolidate a topic branch and
  test things before it gets merged.
  
  So its not a new requirement but it is helpful and appreciated.
 
 It's been over a month and libpng is still broken, so I refuse to
 classify this new process as 'helpful' or as 'appreciated' at this
 point. 

Well, for the past month we've been freezing for and working toward the
release and it was agreed this batch of patches were being queued for
post release. I think that was quite clear.

As you well know, partly this is because we don't have a way to test any
of it, nor is it an officially supported target. If we get a consistent
set of code and a qemu machine that can test it, we'll be in a better
position and I believe that is something people are working towards (but
was way too late for the 1.7 cycle).

We're now in a position where we've started merging patches again, there
is a backlog being worked through and I'm sure this batch will be
presented soon. We are sticking with the stated plan which was to have a
queued branch of those patches, until such times as there is a better
plan or offer.

 If this continues can the person doing such a branch reply to patches
 intended for it saying they will or won't be queued? And please run
 the patches without such a reply through the regular process. That
 would be both helpful and appreciated.

It would be nice if the folks at Linaro would actually present things
like a branch containing theire changes and help with this work. As it
is, it seems others need to do this for them and instead they just want
to complain why we don't take patches (which often don't even seem to
build). I can understand not everyone at Linaro is going to test patches
on a couple of other arches but having someone there aggregating patches
and doing some acid tests might massively improve both their reputation
and increase the chances of patches merging in a timely fashion.

Cheers,

Richard


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

Re: [OE-core] [PATCH 1/1] systemd: add network config while networkd supported

2014-11-03 Thread Enrico Scholz

Hongxu Jia hongxu.jia-cwa4wttnnzf54taoqty...@public.gmane.org writes:

 While networkd supported, we add network config which starts
 dhcp by default.
 ...
 +++ b/meta/recipes-core/systemd/systemd/oe-core.network
 @@ -0,0 +1,8 @@
 +[Match]
 +Name=eth*
 +
 +[Network]
 +DHCP=v4
 +
 +[DHCPv4]
 +UseHostname=false

IMO, this is too much a target specific customization.  DHCP is not
used everywhere; it might conflict with NFS rootfs, there are different
preferences for the DHCP options (UseDomains, VendorClassIdentifier,
CriticalConnection, ...).

It would be better to place this confguration into a separate recipe.


 + install -m 0755 ${WORKDIR}/oe-core.network 
 ${D}${sysconfdir}/systemd/network

You should name this file like '50-oe-core.network' to make it easier to
override it.


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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64


 Op 3 nov. 2014, om 17:08 heeft Burton, Ross ross.bur...@intel.com het 
 volgende geschreven:
 
 
 On 3 November 2014 15:24, Koen Kooi koen.k...@linaro.org wrote:
 It's been over a month and libpng is still broken, so I refuse to classify 
 this new process as 'helpful' or as 'appreciated' at this point.
 
 Remember that 1.7 was frozen solid for several weeks of that month, so no it 
 wouldn't have been merged in that time period.  It's only just re-opened: 
 master is currently 80 patches ahead of dizzy, 35 in the C-Pull I sent last 
 night, and another 33 in my staging branch right now so it's not like we're 
 taking it easy right now.
 
 Some context: during September it was obvious that various parties had an 
 interest in aarch64 (Linaro and Wind River).  Patches to fix build failures 
 were being sent sporadically, a qemuarm64 machine was submitted, but there 
 was no kernel for said machine to actually build.   At the time there was no 
 qemuarm64 machine that actually worked, so even merging the simple fixes on 
 just faith that they're correct would be reckless considering we were 
 freezing.  This is why I suggested[1] that someone with a vested interest in 
 aarch64 collate all the patches into a single branch and keep it rebased to 
 master so that when master opens, it can be tested on *all* qemu 
 architectures and merged.  It appears that this hasn't happened.  Will Linaro 
 be able to create a branch that incorporates all of the patches and new 
 machine that's been tested as a whole?

Most likely not because we already have meta-aarch64 for the toolchain and 
kernel support. But aside from that, the past few *years* it wasn't a problem 
to get aarch64 related patches merged into OE-core, so why is there suddenly 
such a problem now?

Furthermore, this libpng patch isn't strictly an aarch64 patch, it fixes a 
previous commit that should have been flagged in review as being wrong for 
using double qualifiers in a bogus way. So why did the culprit go in and the 
fix submitted 3 days later not?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Specifying 32 bit dependency for 64 bit software

2014-11-03 Thread Laszlo Papp

Hi,

we have a tool that we run during our make run, but this tool is
hard-coded for 32 bit. It depends on software like ncurses. I could
add ncurses-native in an ideal world; no problem.

The problem is that my host environment is 64 bit currently and it is
not possible to migrate the whole environment to 32 bit. I am happy to
explain the details if needed, but I would love you to trust me about
that. =)

So, is it possible to say more than just DEPENDS = ncurses-native,
something like DEPENDS = ncurses-native:x86 or something?

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

Re: [OE-core] [PATCH] package_manager: Fix populate_sdk for dpkg packages


Ricardo,

I think the problem isn't related to this, the all_arch_list is set to 
archs + multilib_archs see the __init__ func.


Best regards.

On 01/11/14 10:57, Ricardo Ribalda Delgado wrote:

Without this patch:

ERROR: Unable to install packages. Command 
'/var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/sysroots/x86_64-linux/usr/bin/apt-get
  install --force-yes --allow-unauthenticated nativesdk-packagegroup-sdk-host 
packagegroup-cross-canadian-qt5022' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
W: Unable to read 
/var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/meta-toolchain/1.0-r7/apt-sdk/preferences.d/
 - DirectoryExists (2: No such file or directory)
E: Unable to locate package nativesdk-packagegroup-sdk-host
E: Unable to locate package packagegroup-cross-canadian-qt5022

ERROR: Function failed: do_populate_sdk
ERROR: Logfile of failure stored in: 
/var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/meta-toolchain/1.0-r7/temp/log.do_populate_sdk.4926
NOTE: recipe meta-toolchain-1.0-r7: task do_populate_sdk: Failed
ERROR: Task 7 
(/var/lib/jenkins/jobs/qt5022-cesium/workspace/repo/yocto/meta/recipes-core/meta/meta-toolchain.bb,
 do_populate_sdk) failed with exit code '1'
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---

Tested on yocto 1.7

Only build test, not tested on target.

  meta/lib/oe/package_manager.py | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 27fdf26..8828bce 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -188,7 +188,7 @@ class DpkgIndexer(Indexer):
  release.write(Label: %s\n % arch)
  
  cmd += PSEUDO_UNLOAD=1 %s release .  Release % apt_ftparchive

-
+
  index_cmds.append(cmd)
  
  deb_dirs_found = True

@@ -1467,6 +1467,7 @@ class DpkgPM(PackageManager):
  def __init__(self, d, target_rootfs, archs, base_archs, 
apt_conf_dir=None):
  super(DpkgPM, self).__init__(d)
  self.target_rootfs = target_rootfs
+self.pkg_archs = archs
  self.deploy_dir = self.d.getVar('DEPLOY_DIR_DEB', True)
  if apt_conf_dir is None:
  self.apt_conf_dir = self.d.expand(${APTCONF_TARGET}/apt)
@@ -1662,7 +1663,7 @@ class DpkgPM(PackageManager):
  bb.utils.mkdirhier(self.apt_conf_dir + /apt.conf.d/)
  
  arch_list = []

-for arch in self.all_arch_list:
+for arch in self.pkg_archs.split():
  if not os.path.exists(os.path.join(self.deploy_dir, arch)):
  continue
  arch_list.append(arch)


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

Re: [OE-core] Specifying 32 bit dependency for 64 bit software

2014-11-03 Thread Laszlo Papp

Forgot to mention, but any nice workarounds are appreciated. I have a
few ideas, but they are all a bit ugly and non-robust.

On Mon, Nov 3, 2014 at 5:29 PM, Laszlo Papp lp...@kde.org wrote:
 Hi,

 we have a tool that we run during our make run, but this tool is
 hard-coded for 32 bit. It depends on software like ncurses. I could
 add ncurses-native in an ideal world; no problem.

 The problem is that my host environment is 64 bit currently and it is
 not possible to migrate the whole environment to 32 bit. I am happy to
 explain the details if needed, but I would love you to trust me about
 that. =)

 So, is it possible to say more than just DEPENDS = ncurses-native,
 something like DEPENDS = ncurses-native:x86 or something?

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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

On 3 November 2014 17:13, Koen Kooi k...@dominion.thruhere.net wrote:

 Most likely not because we already have meta-aarch64 for the toolchain and
 kernel support. But aside from that, the past few *years* it wasn't a
 problem to get aarch64 related patches merged into OE-core, so why is there
 suddenly such a problem now?


Because oe-core was frozen and we were only taking serious fixes.  Now
there's a number of related patches that can and should be bundled up so
they can be tested as a whole.


 Furthermore, this libpng patch isn't strictly an aarch64 patch, it fixes a
 previous commit that should have been flagged in review as being wrong for
 using double qualifiers in a bogus way. So why did the culprit go in and
 the fix submitted 3 days later not?


That patch in particular?  Because humans are not infallible.  FWIW, this
is in my MUT now.

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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

2014-11-03 Thread Mark Hatle


On 11/3/14, 9:24 AM, Koen Kooi wrote:


Op 3 nov. 2014, om 13:10 heeft Richard Purdie 
richard.pur...@linuxfoundation.org het volgende geschreven:


On Mon, 2014-11-03 at 13:06 +0100, Koen Kooi wrote:

Op 3 nov. 2014, om 12:30 heeft Burton, Ross ross.bur...@intel.com het 
volgende geschreven:


On 3 November 2014 11:27, Koen Kooi k...@dominion.thruhere.net wrote:

Last night I was looking at my post-1.7 tag and the number of aarch64 patches 
there.   Kai, did you continue work on that staging branch for all of the aarch64 patches 
that were being posted?


What does that have to do with this patch?

Kai was collecting patches that were sent to oe-core, and this may have been 
one of them.


Is this some new requirement for OE-core patches?


Its someone being helpful and trying to consolidate a topic branch and
test things before it gets merged.

So its not a new requirement but it is helpful and appreciated.


It's been over a month and libpng is still broken, so I refuse to classify this 
new process as 'helpful' or as 'appreciated' at this point.

If this continues can the person doing such a branch reply to patches intended 
for it saying they will or won't be queued? And please run the patches without 
such a reply through the regular process. That would be both helpful and 
appreciated.


We've been attempting to aggregate what we (WR) can in:

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

But as it's unofficial and we're simply trying to keep the patches we know of 
together..  you'll have to be patient.  The first order of business is getting a 
functional qemuarm64.. it's MOSTLY there, but we're having toolchain issues and 
other things that are simply higher priority for us.


As for libpng, we have a different version of the patch in that branch...  it 
was enough to get around the problem in question, but may not be the correct fix.


--Mark


--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs





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

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

On 3 November 2014 17:38, Mark Hatle mark.ha...@windriver.com wrote:

 We've been attempting to aggregate what we (WR) can in:

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

 But as it's unofficial and we're simply trying to keep the patches we know
 of together..  you'll have to be patient.  The first order of business is
 getting a functional qemuarm64.. it's MOSTLY there, but we're having
 toolchain issues and other things that are simply higher priority for us.


Great, thanks Mark.  A functional qemuarm64 that boots core-image-minimal
is a good step in the right direction, then we can experiment with it on
the autobuilder. :)

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

Re: [OE-core] [PATCH v2] shadow: enable support for subordinate IDs

On 3 November 2014 13:09, bogdan.purcare...@freescale.com 
bogdan.purcare...@freescale.com wrote:

 Can someone kindly review my patch? I haven't sent patches to this list
 yet and I don't know who the maintainer is.


This was incorporated into my consolidated pull on Sunday, so expect to see
it merged into master shortly.

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

Re: [OE-core] [PATCH 0/3] prevent pseudo host passwd/group contamination

2014-11-03 Thread Peter Seebach

On Sat, 1 Nov 2014 12:04:36 -0500
Peter A. Bigot p...@pabigot.com wrote:

 The new patches use --without-passwd-fallback, preventing contamination
 from the host files during the early build stages when the target
 versions from base-passwd aren't yet available.

I like these, and will see whether I can free up time to work on this. If I
can't, though, I have no objections to these (and the previous set) being
added to oe-core as local patches until next time I have a free day or two to
study the password code.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] package_manager: Fix populate_sdk for dpkg packages


Ricardo,

I figured out the reason for this problem when rootfs is creating then 
uses PACKAGE_ARCHS but when is creating sdk for host SDK_PACKAGE_ARCHS is
used, now i'm fixing DpkgPM set self.all_arch_list variable from 
PACKAGE_ARCHS to passed archs var.


I'll send new patch soon.

Thanks.

On 03/11/14 11:27, Aníbal Limón wrote:

Ricardo,

I think the problem isn't related to this, the all_arch_list is set to 
archs + multilib_archs see the __init__ func.


Best regards.

On 01/11/14 10:57, Ricardo Ribalda Delgado wrote:

Without this patch:

ERROR: Unable to install packages. Command 
'/var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/sysroots/x86_64-linux/usr/bin/apt-get 
install --force-yes --allow-unauthenticated 
nativesdk-packagegroup-sdk-host packagegroup-cross-canadian-qt5022' 
returned 100:

Reading package lists...
Building dependency tree...
Reading state information...
W: Unable to read 
/var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/meta-toolchain/1.0-r7/apt-sdk/preferences.d/ 
- DirectoryExists (2: No such file or directory)

E: Unable to locate package nativesdk-packagegroup-sdk-host
E: Unable to locate package packagegroup-cross-canadian-qt5022

ERROR: Function failed: do_populate_sdk
ERROR: Logfile of failure stored in: 
/var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/meta-toolchain/1.0-r7/temp/log.do_populate_sdk.4926

NOTE: recipe meta-toolchain-1.0-r7: task do_populate_sdk: Failed
ERROR: Task 7 
(/var/lib/jenkins/jobs/qt5022-cesium/workspace/repo/yocto/meta/recipes-core/meta/meta-toolchain.bb, 
do_populate_sdk) failed with exit code '1'

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---

Tested on yocto 1.7

Only build test, not tested on target.

  meta/lib/oe/package_manager.py | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/package_manager.py 
b/meta/lib/oe/package_manager.py

index 27fdf26..8828bce 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -188,7 +188,7 @@ class DpkgIndexer(Indexer):
  release.write(Label: %s\n % arch)
cmd += PSEUDO_UNLOAD=1 %s release .  Release % 
apt_ftparchive

-
+
  index_cmds.append(cmd)
deb_dirs_found = True
@@ -1467,6 +1467,7 @@ class DpkgPM(PackageManager):
  def __init__(self, d, target_rootfs, archs, base_archs, 
apt_conf_dir=None):

  super(DpkgPM, self).__init__(d)
  self.target_rootfs = target_rootfs
+self.pkg_archs = archs
  self.deploy_dir = self.d.getVar('DEPLOY_DIR_DEB', True)
  if apt_conf_dir is None:
  self.apt_conf_dir = self.d.expand(${APTCONF_TARGET}/apt)
@@ -1662,7 +1663,7 @@ class DpkgPM(PackageManager):
  bb.utils.mkdirhier(self.apt_conf_dir + /apt.conf.d/)
arch_list = []
-for arch in self.all_arch_list:
+for arch in self.pkg_archs.split():
  if not os.path.exists(os.path.join(self.deploy_dir, 
arch)):

  continue
  arch_list.append(arch)




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

[OE-core] [PATCH] package_manager: DpkgPM fix populate_sdk

DpkgPM change all_arch_list variable set from PACKAGE_ARCHS to passed
archs variable because is different when is executed from rootfs.py
and sdk.py.

Credits to: Ricardo Ribalda ricardo.riba...@gmail.com

Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
 meta/lib/oe/package_manager.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index ffb83b2..e44e28a 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -1478,7 +1478,7 @@ class DpkgPM(PackageManager):
 
 self.apt_args = d.getVar(APT_ARGS, True)
 
-self.all_arch_list = self.d.getVar('PACKAGE_ARCHS', True).split()
+self.all_arch_list = archs.split()
 all_mlb_pkg_arch_list = (self.d.getVar('ALL_MULTILIB_PACKAGE_ARCHS', 
True) or ).replace('-', '_').split()
 self.all_arch_list.extend(arch for arch in all_mlb_pkg_arch_list if 
arch not in self.all_arch_list)
 
-- 
1.9.1

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

Re: [OE-core] [PATCH 0/3] prevent pseudo host passwd/group contamination

On 3 November 2014 18:55, Peter Seebach peter.seeb...@windriver.com wrote:

  The new patches use --without-passwd-fallback, preventing contamination
  from the host files during the early build stages when the target
  versions from base-passwd aren't yet available.

 I like these, and will see whether I can free up time to work on this. If I
 can't, though, I have no objections to these (and the previous set) being
 added to oe-core as local patches until next time I have a free day or two
 to
 study the password code.


Thanks Peter(s), these are now  in my staging branch for master.

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

[OE-core] [PATCH] perl: Fix bug when installs SDK in custom directory