Re: [OE-core] [PATCH] libtool: Add depends on binutils-cross
On Mar 31, 2014, at 11:37 PM, Zongchun YU wrote: > Sorry to confuse you. Sometimes libtool have been built but the > binutils-cross have't been built yet. > It is required by libtool. OK is it cross, native or target recipe which has the problem ? wouldnt it need to also depend on gcc-cross ? signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On Mar 31, 2014, at 12:50 PM, Bruce Ashfield wrote: >> i dont believe you tested all layer combinations > > I've tested everything I can, as has the autobuilder. I can't offer > any more than this. > >> > >> > >> >> at this point. 3.10 being LTS >> >> I would assume its a better option to keep at 3.10 >> > >> > >> > I disagree, this is consistent with other releases and the documented >> > plan of action. I'd rather not have a massive version jump in the fall. >> >> its probably not a bad option to stick to LTS version for kernel headers >> after all > > Again, I disagree. > > We can maybe keep the 3.10 recipe around, Thats ugly too. We decided to stick to one version of headers last time. > but the default should > be 3.14, we need a matched kernel and libc-headers to get the best integration > and leveraging of the latest features. > > If we pull the headers, pull the kernel. this all is understood, however we have to get better with timings especially changing something like kernel headers whose impact is far reaching then just updating kernel proper. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add depends on binutils-cross
>can you explain the race a bit here. Sorry to confuse you. Sometimes libtool have been built but the binutils-cross have't been built yet. It is required by libtool. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add depends on binutils-cross
On Mar 31, 2014, at 11:12 PM, wrote: > From: Zongchun Yu > > When use command bitbake -c populate_sdk to > generate toolchain. a race issue may occur. in this case need > to add binutils-cross to depends. > can you explain the race a bit here. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libtool: Add depends on binutils-cross
From: Zongchun Yu
When use command bitbake -c populate_sdk to
generate toolchain. a race issue may occur. in this case need
to add binutils-cross to depends.
Signed-off-by: Zongchun Yu
---
meta/recipes-devtools/libtool/libtool-2.4.2.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
index d26982d..0868dd7 100644
--- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
+++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
@@ -36,7 +36,7 @@ do_compile_prepend () {
inherit autotools
EXTRA_AUTORECONF = "--exclude=libtoolize"
-DEPENDS = "libtool-native"
+DEPENDS = "libtool-native binutils-cross"
PACKAGES =+ "libltdl libltdl-dev libltdl-dbg libltdl-staticdev"
FILES_${PN} += "${datadir}/aclocal"
--
1.7.0.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-arch: Always use ld.bfd to link the kernel
On Fri, Mar 28, 2014 at 10:28 AM, Denys Dmytriyenko wrote:
>> -KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld ${HOST_LD_KERNEL_ARCH}"
>> +KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
>> KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
>
> I know this is almost a year-old change.
>
> The question I have is - what should one do when using an external toolchain
> that doesn't have ld.bfd provided? I know these days with gold vs. BFD linker,
> it's common to have ld.bfd, but there could be exceptions...
>
> Should this assignment be conditional, so it's easier to override from
> local.conf or distro?
Can external toolchain create ld.bfd symlink ?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Make ppce300c3 tune hard-float by default
Mats
On Fri, Mar 28, 2014 at 9:43 AM, Mats Kärrman wrote:
> +# glibc configure options to make use of 603e specific sqrt/sqrtf routines
> +GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3",
> "--with-cpu=e300c3", "", d)}"
looks good, may be the comment above can be more explanatory saying that
glibc aliases e300c3 sqrt/sqrtf to 600e versions
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] libarchive: fix CVE-2013-0211
On Fri, Mar 28, 2014 at 2:43 AM, Hongxu Jia wrote: > ++ const size_t max_write = INT_MAX; I think INT_MAX is a mismatch here size_t may not be defined 'unsigned int' on all kind of architectures. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OE monthy today (?)
On Tue, Apr 01, 2014 at 12:52:52AM -0400, Trevor Woerner wrote: > On 04/01/14 00:34, Denys Dmytriyenko wrote: > > On Tue, Apr 01, 2014 at 12:04:16AM -0400, Trevor Woerner wrote: > >> ...in roughly 12 hours from now? > > ? > > I'm referring to the monthly OE meeting that's held on IRC. I'm trying > to confirm it takes place today and is scheduled for noon EST. Did you mean TSC/workgroup meeting? Nothing from Paul yet... -- Denys -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OE monthy today (?)
On 04/01/14 00:34, Denys Dmytriyenko wrote: > On Tue, Apr 01, 2014 at 12:04:16AM -0400, Trevor Woerner wrote: >> ...in roughly 12 hours from now? > ? I'm referring to the monthly OE meeting that's held on IRC. I'm trying to confirm it takes place today and is scheduled for noon EST. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OE monthy today (?)
On Tue, Apr 01, 2014 at 12:04:16AM -0400, Trevor Woerner wrote: > ...in roughly 12 hours from now? ? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OE monthy today (?)
...in roughly 12 hours from now? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] udev-extraconf: update mount.sh to use /run/media instead of /media
From: Denys Dmytriyenko
This is done to work around the issue of auto-mounting block devices
(i.e. SD cards) when root filesystem is still in read-only mode and
creating /media/ mount-points by udev is not possible. That
is due to udev (/etc/rcS.d/S03udev) getting started earlier than
checkroot (/etc/rcS.d/S10checkroot.sh) gets a chance to re-mount the
rootfs as read-write.
Although, canonical FHS specifies /media/ as a mount point
for removable media devices, the latest 2.3 version was released in
2004 and since then FreeDesktop/udisks and other tools adopted the
new /run/media// location. That was done to overcome
read-only rootfs limitation, since /run is usually a tmpfs mounted
partition, plus avoid name-clash between users.
For our embedded systems environment we assume single-user operation
and hence simplify mount point to just /run/media/. But for
proper per-user mounting to /run/media//, some sort of
session management is required along with the tool like udisks, that
is out of scope of this simple udev-based auto-mounting.
Signed-off-by: Denys Dmytriyenko
---
v2 - drop PR, bump PV, elaborate on session/user mounting option
meta/recipes-core/udev/udev-extraconf/mount.sh | 14 +++---
.../udev/{udev-extraconf_1.0.bb => udev-extraconf_1.1.bb} | 2 --
2 files changed, 7 insertions(+), 9 deletions(-)
rename meta/recipes-core/udev/{udev-extraconf_1.0.bb => udev-extraconf_1.1.bb}
(99%)
diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index cb57e47..3e4f21f 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -20,7 +20,7 @@ done
automount() {
name="`basename "$DEVNAME"`"
- ! test -d "/media/$name" && mkdir -p "/media/$name"
+ ! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
# Silent util-linux's version of mounting auto
if [ "x`readlink $MOUNT`" = "x/bin/mount.util-linux" ] ;
then
@@ -38,12 +38,12 @@ automount() {
;;
esac
- if ! $MOUNT -t auto $DEVNAME "/media/$name"
+ if ! $MOUNT -t auto $DEVNAME "/run/media/$name"
then
- #logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME
\"/media/$name\" failed!"
- rm_dir "/media/$name"
+ #logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME
\"/run/media/$name\" failed!"
+ rm_dir "/run/media/$name"
else
- logger "mount.sh/automount" "Auto-mount of [/media/$name]
successful"
+ logger "mount.sh/automount" "Auto-mount of [/run/media/$name]
successful"
touch "/tmp/.automount-$name"
fi
}
@@ -60,7 +60,7 @@ rm_dir() {
# No ID_FS_TYPE for cdrom device, yet it should be mounted
name="`basename "$DEVNAME"`"
-[ -e /sys/block/$name/device/media ] && media_type=`cat
/sys/block/$name/device/media`
+[ -e /sys/block/$name/device/run/media ] && media_type=`cat
/sys/block/$name/device/run/media`
if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && [ -n "$ID_FS_TYPE" -o
"$media_type" = "cdrom" ]; then
if [ -x "$PMOUNT" ]; then
@@ -87,5 +87,5 @@ if [ "$ACTION" = "remove" ] && [ -x "$UMOUNT" ] && [ -n
"$DEVNAME" ]; then
# Remove empty directories from auto-mounter
name="`basename "$DEVNAME"`"
- test -e "/tmp/.automount-$name" && rm_dir "/media/$name"
+ test -e "/tmp/.automount-$name" && rm_dir "/run/media/$name"
fi
diff --git a/meta/recipes-core/udev/udev-extraconf_1.0.bb
b/meta/recipes-core/udev/udev-extraconf_1.1.bb
similarity index 99%
rename from meta/recipes-core/udev/udev-extraconf_1.0.bb
rename to meta/recipes-core/udev/udev-extraconf_1.1.bb
index 3810b28..d69056d 100644
--- a/meta/recipes-core/udev/udev-extraconf_1.0.bb
+++ b/meta/recipes-core/udev/udev-extraconf_1.1.bb
@@ -4,8 +4,6 @@ LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-PR = "r16"
-
SRC_URI = " \
file://automount.rules \
file://mount.sh \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel: don't populate source symbolic link
From: Ming Liu
/usr/src/kernel/source deployed by kernel-dev package is symbolically
linking to a build-time kernel source folder, which make no sense when
cross-compiling.
Fixed by not populating it at install stage.
Signed-off-by: Ming Liu
Signed-off-by: Kai Kang
---
meta/classes/kernel.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 19b159b..6ed1cb7 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -232,7 +232,7 @@ kernel_do_install() {
# dir. This ensures the original Makefiles are used and not the
# redirecting Makefiles in the build directory.
#
- find . -depth -not -name "*.cmd" -not -name "*.o" -not -path
"./Documentation*" -not -path "./.*" -print0 | cpio --null -pdlu $kerneldir
+ find . -depth -not -name "*.cmd" -not -name "*.o" -not -path
"./Documentation*" -not -path "./source*" -not -path "./.*" -print0 | cpio
--null -pdlu $kerneldir
cp .config $kerneldir
if [ "${S}" != "${B}" ]; then
pwd="$PWD"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bash-3.2.48: fix error path of getc_with_restart
From: Yong Zhang
1. let getc_with_restart() handle EAGAIN|EWOULDBLOCK
correctly.
2. When read() returns with ERROR, local_bufused will be set
to -1; and if we return with local_bufused == -1 left,
the next time we call getc_with_restart(), the condition
(local_index == local_bufused || local_bufused == 0)
will not match, thus we get random data from localbuf[]
with local_index increased each time, eventually we may
access data beyond array localbuf[]. Fix it by resetting
local_index and local_bufused in case of read failure.
Signed-off-by: Yong Zhang
Signed-off-by: Kai Kang
---
.../bash-fix-error-path-of-getc_with_restart.patch | 41 ++
.../bash-3.2.48/bash-fix-getc_with_restart.patch | 28 +++
meta/recipes-extended/bash/bash_3.2.48.bb | 2 ++
3 files changed, 71 insertions(+)
create mode 100644
meta/recipes-extended/bash/bash-3.2.48/bash-fix-error-path-of-getc_with_restart.patch
create mode 100644
meta/recipes-extended/bash/bash-3.2.48/bash-fix-getc_with_restart.patch
diff --git
a/meta/recipes-extended/bash/bash-3.2.48/bash-fix-error-path-of-getc_with_restart.patch
b/meta/recipes-extended/bash/bash-3.2.48/bash-fix-error-path-of-getc_with_restart.patch
new file mode 100644
index 000..045124f
--- /dev/null
+++
b/meta/recipes-extended/bash/bash-3.2.48/bash-fix-error-path-of-getc_with_restart.patch
@@ -0,0 +1,41 @@
+Upstream-Status: Accepted
+
+When read() returns with ERROR, local_bufused will be set
+to -1; and if we return with local_bufused == -1 left,
+the next time we call getc_with_restart(), the condition
+(local_index == local_bufused || local_bufused == 0)
+will not match, thus we get random data from localbuf[]
+with local_index increased each time, eventually we may
+access data beyond array localbuf[]. Fix it by resetting
+local_index and local_bufused in case of read failure.
+
+Merged by:
+http://git.savannah.gnu.org/cgit/bash.git/commit/input.c?id=ac50fbac377e32b98d2de396f016ea81e8ee9961
+
+Signed-off-by: Yong Zhang
+Signed-off-by: Kai Kang
+---
+ input.c |7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/input.c
b/input.c
+@@ -78,12 +78,17 @@ getc_with_restart (stream)
+ else if (errno == EAGAIN || errno == EWOULDBLOCK)
+ {
+ if (sh_unset_nodelay_mode (fileno (stream)) < 0)
+- return EOF;
++ {
++local_index = 0;
++local_bufused = 0;
++return EOF;
++ }
+ continue;
+ }
+ else if (local_bufused == 0 || errno != EINTR)
+ {
+ local_index = 0;
++local_bufused = 0;
+ return EOF;
+ }
+ }
diff --git
a/meta/recipes-extended/bash/bash-3.2.48/bash-fix-getc_with_restart.patch
b/meta/recipes-extended/bash/bash-3.2.48/bash-fix-getc_with_restart.patch
new file mode 100644
index 000..45d93b1
--- /dev/null
+++ b/meta/recipes-extended/bash/bash-3.2.48/bash-fix-getc_with_restart.patch
@@ -0,0 +1,28 @@
+Upstream-Status: Accepted
+
+Let getc_with_restart() handle EAGAIN|EWOULDBLOCK correctly.
+
+Merged by:
+http://git.savannah.gnu.org/cgit/bash.git/commit/input.c?id=3185942a5234e26ab13fa02f9c51d340cec514f8
+
+Signed-off-by: Yong Zhang
+Signed-off-by: Kai Kang
+---
+ input.c |6 ++
+ 1 file changed, 6 insertions(+)
+
+--- a/input.c
b/input.c
+@@ -75,6 +75,12 @@ getc_with_restart (stream)
+ local_bufused = read (fileno (stream), localbuf, sizeof(localbuf));
+ if (local_bufused > 0)
+ break;
++else if (errno == EAGAIN || errno == EWOULDBLOCK)
++ {
++if (sh_unset_nodelay_mode (fileno (stream)) < 0)
++ return EOF;
++continue;
++ }
+ else if (local_bufused == 0 || errno != EINTR)
+ {
+ local_index = 0;
diff --git a/meta/recipes-extended/bash/bash_3.2.48.bb
b/meta/recipes-extended/bash/bash_3.2.48.bb
index fe04b28..619c3ad 100644
--- a/meta/recipes-extended/bash/bash_3.2.48.bb
+++ b/meta/recipes-extended/bash/bash_3.2.48.bb
@@ -13,6 +13,8 @@ SRC_URI = "${GNU_MIRROR}/bash/bash-${PV}.tar.gz;name=tarball \
file://build-tests.patch \
file://test-output.patch \
file://run-ptest \
+ file://bash-fix-getc_with_restart.patch;striplevel=1 \
+ file://bash-fix-error-path-of-getc_with_restart.patch;striplevel=1 \
"
SRC_URI[tarball.md5sum] = "338dcf975a93640bb3eaa843ca42e3f8"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Fix some bash errors
Fix some errors for bash 3.2.48 by take patches from bash 4.3. Yong Zhang (1): bash-3.2.48: fix error path of getc_with_restart .../bash-fix-error-path-of-getc_with_restart.patch | 41 ++ .../bash-3.2.48/bash-fix-getc_with_restart.patch | 28 +++ meta/recipes-extended/bash/bash_3.2.48.bb | 2 ++ 3 files changed, 71 insertions(+) create mode 100644 meta/recipes-extended/bash/bash-3.2.48/bash-fix-error-path-of-getc_with_restart.patch create mode 100644 meta/recipes-extended/bash/bash-3.2.48/bash-fix-getc_with_restart.patch -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world, Failed tasks 2014-03-29
On Mon, Mar 31, 2014 at 06:17:25PM -0700, Adam Lee wrote: > I took a look into these three (in hopes of free beer): > > polkit-gnome: configure was passed unrecognised options: > --disable-scrollkeeper --disable-man-pages > > gnome-bluetooth-2.32.0: gnome-bluetooth: configure was passed > unrecognised options: --disable-schemas-install > > openobex-1.5: openobex: configure was passed unrecognised options: > --with-usb --with-bluez > > > And it looks like all three package recipes are more or less the same > as the ones in Dora. So I am confused why they haven't come up before > (say, in Dora). Are we doing more strict config flag checking anywhere > that I am unaware of? yes, infodir and unrecognized options weren't reported before (we even had almost clean qa report around dora branch). > Also, sound-theme-freedesktop has been blocking my build for a while. I see > JaMa has a local commit, but I am not sure if that's the fix for the build > failure we see in the report. Can someone provide tips on that nasty > undefined macro? yes, it's fixing that, I've also fixed most --disable-schemas-install warnings and warnings about infodir, you can see latest changes I have locally (and now running on jenkins) in: https://github.com/shr-distribution/meta-oe/commits/jansa/test I'll send them to ML when they pass at least first jenkins build without causing more issues than what they are fixing. > On Sat, Mar 29, 2014 at 5:28 PM, Martin Jansa wrote: > > > On Sat, Mar 29, 2014 at 11:54:32PM +0100, Martin Jansa wrote: > > > On Wed, Mar 26, 2014 at 06:11:36PM +0100, Martin Jansa wrote: > > > > On Sun, Mar 23, 2014 at 09:43:24PM +0100, Martin Jansa wrote: > > > > > On Tue, Mar 18, 2014 at 07:50:08PM +0100, Martin Jansa wrote: > > > > > > On Sat, Mar 15, 2014 at 03:10:46PM +0100, Martin Jansa wrote: > > > > > > > On Tue, Mar 11, 2014 at 02:50:14PM +0100, Martin Jansa wrote: > > > > > > > > On Tue, Mar 11, 2014 at 02:45:04PM +0100, Martin Jansa wrote: > > > > > > > > > Biggest difference from last e-mail is aclocal changes which > > can possibly explain > > > > > > > > > increased number of do_configure failures, I've asked > > Richard to delay merging B!=S > > > > > > > > > change until we resolve or at least analyze these new > > failures, so any help with > > > > > > > > > would be highly appreciated. > > > > > > http://www.openembedded.org/wiki/Bitbake_World_Status > > > > > > == Failed tasks 2014-03-29 == > > > > Be aware that I plan to run test-dependencies script for next few days, > > so changes to meta-oe will be delayed until it's finished and I can use > > jenkins again to test incoming changes. > > > > If you want to do something really useful and you're not confident with > > "big" changes, please scan qa.log files in URLs in report and send some > > small patches to resolve unrecognized configure options (check the > > configure > > script if the option was replaced by something or if there is typo or if > > it is applied by some bbclass which possibly shouldn't be used e.g. > > gnome/gnombase). I offer beer on ELC for everybody who sends 10 changes > > like this :). > > > > It won't show much, because a lot of recipes are still blocked by issues > > listed bellow, but because release is close it's better to run it now > > and fix at least found issues, before the release. > > > > I also have couple of local changes which I haven't sent yet, because > > they aren't properly tested: > > > > f2e1f65 libgnomecanvas: add intltool dependency > > cc3dac2 edbus: remove test-gui option > > eff6aaa zram: include whole sysconfdir in PN > > d308e37 atftp: include whole sysconfdir in PN > > cdfd489 metacity: inherit only gnomebase > > f415c1f gtksourceview2: inherit only gnomebase > > 85550a0 goffice: inherit only gnomebase > > 22a1a79 zenity: inherit only gnomebase > > 29c844e gnome-themes: inherit only gnomebase > > 561c24c gnome-backgrounds: inherit only gnomebase > > 49fb47b gcr: inherit only gnomebase > > b470935 modemmanager: inherit only gnomebase > > bdc4cd9 libbonobo: inherit only gnomebase > > 2b13d00 libgnome-keyring: inherit only gnomebase > > fb2406f gnome-disk-utility: inherit only gnomebase > > 58a1d87 libgdata: inherit only gnomebase > > 6141925 libgtop: inherit only gnomebase > > 8c021f1 gnome-bluetooth: inherit only gnomebase > > 8723ea9 dconf: inherit only gnomebase > > e63ca45 babl: inherit only gnomebase > > bea1f1d gnome-menus: inherit only gnomebase > > a33e667 wvstreams: fix QA warning > > 7aa1b5e elementary: remove --disable-web > > 6e3a7c8 libwnck*: inherit only gnomebase > > 7855b14 tracker: inherit only gnomebase, fix QA warn > > 3251a4e gnome-control-center: include datadir/mime in PN > > 0ee66bb freerdp: move to nonworking > > de68ce6 sound-theme-freedesktop: add glib-2.0 dependenecy > > 5fac747 libdc1394: add libsdl dependency > > 4609314 mplayer2: bump SRCREV to fix build issues with newer live555 > > e403bec gvfs-gdu-volume-monitor: Define build dependency on > > libgnome-keyr
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On 2014年04月01日 00:32, Richard Purdie wrote:
On Mon, 2014-03-31 at 17:10 +0200, Martin Jansa wrote:
On Mon, Mar 31, 2014 at 10:20:49PM +0800, Kai Kang wrote:
From: Roy Li
When native package is built, use the uname to return the kernel version.
When target is built, read kernel version from
${STAGING_KERNEL_DIR}/kernel-abiversion
to avoid to use the hardcode kernel version.
Doesn't it make nss MACHINE_ARCH like most virtual/kernel providers are?
Agreed. I rejected this patch a while ago due to this and I'll reject it
again.
Got it. Thanks for all of your comments.
--Kai
Cheers,
Richard
--
Regards,
Neil | Kai Kang
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] util-linux-native: fix qsort_r for CentOS 5.10
On 04/01/2014 05:22 AM, Paul Barker wrote:
On 26 March 2014 07:01, Robert Yang wrote:
The qsort_r() was added to glibc in version 2.8, so there is no qsort_r() on
the host like CentOS 5.x, use qsort() to fix it since they are nearly
identical.
Signed-off-by: Robert Yang
---
.../util-linux/util-linux-native-qsort.patch | 34
meta/recipes-core/util-linux/util-linux_2.24.1.bb |4 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
diff --git
a/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
b/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
new file mode 100644
index 000..1707683
--- /dev/null
+++ b/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
@@ -0,0 +1,34 @@
+From f220d809be1baa654503bf6ff52f3630b0d7015c Mon Sep 17 00:00:00 2001
+From: Robert Yang
+Date: Wed, 26 Mar 2014 01:30:29 +
+Subject: [PATCH] sun.c: use qsort() to instead of qsort_r()
+
+qsort_r() was added to glibc in version 2.8, so there is no qsort_r() on
+the host like CentOS 5.x.
+
+Upstream-Status: Inappropriate [Other]
+
+Signed-off-by: Robert Yang
+---
+ libfdisk/src/sun.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/libfdisk/src/sun.c b/libfdisk/src/sun.c
+index e73c701..f7899ec 100644
+--- a/libfdisk/src/sun.c
b/libfdisk/src/sun.c
+@@ -427,9 +427,8 @@ static int sun_verify_disklabel(struct fdisk_context *cxt)
+ else
+ array[i] = -1;
+ }
+-qsort_r(array,ARRAY_SIZE(array),sizeof(array[0]),
+-(int (*)(const void *,const void *,void *)) verify_sun_cmp,
+-verify_sun_starts);
++qsort(array,ARRAY_SIZE(array),sizeof(array[0]),
++(int (*)(const void *,const void *)) verify_sun_cmp);
I've just been looking at this for building util-linux on top of musl
(as musl-libc doesn't implement qsort_r)
and my solution was to import a qsort_r implementation from ccl
(https://ccl.googlecode.com/svn/trunk/qsort_r.c).
Maybe we can do it in YP 1.7.
Are you sure this solution works? verify_sun_cmp takes 3 parameters
not 2 and it uses the 3rd parameter (data). From reading this I'd
imagine a segfault is likely to occur in verify_sun_cmp if qsort is
used instead of qsort_r.
I think it works well since there is a similar patch before we upgrade
the util-linux-native, I will verify later.
// Robert
+
+ if (array[0] == -1) {
+ fdisk_info(cxt, _("No partitions defined."));
+--
+1.8.2.1
+
diff --git a/meta/recipes-core/util-linux/util-linux_2.24.1.bb
b/meta/recipes-core/util-linux/util-linux_2.24.1.bb
index aa98b65..ab80ab6 100644
--- a/meta/recipes-core/util-linux/util-linux_2.24.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.24.1.bb
@@ -4,7 +4,9 @@ require util-linux.inc
# To support older hosts, we need to patch and/or revert
# some upstream changes. Only do this for native packages.
OLDHOST = ""
-OLDHOST_class-native = "file://util-linux-native.patch"
+OLDHOST_class-native = "file://util-linux-native.patch \
+file://util-linux-native-qsort.patch \
+ "
SRC_URI += "file://util-linux-ng-replace-siginterrupt.patch \
file://util-linux-ng-2.16-mount_lock_path.patch \
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Thanks,
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 1/1] dbus: fix a hard dependency about dbus-ptest
Ping On 03/19/2014 07:59 PM, Burton, Ross wrote: On 19 March 2014 02:00, Chong Lu wrote: If image contains dbus and ptest is in DISTRO_FEATURES, dbus-ptest package is installed, regardless of whether ptest-pkgs is in IMAGE_FEATURES. This issue will increase size for most small images. This patch fixes this problem. Reviewed-by: Ross Burton Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world, Failed tasks 2014-03-29
I took a look into these three (in hopes of free beer): polkit-gnome: configure was passed unrecognised options: --disable-scrollkeeper --disable-man-pages gnome-bluetooth-2.32.0: gnome-bluetooth: configure was passed unrecognised options: --disable-schemas-install openobex-1.5: openobex: configure was passed unrecognised options: --with-usb --with-bluez And it looks like all three package recipes are more or less the same as the ones in Dora. So I am confused why they haven't come up before (say, in Dora). Are we doing more strict config flag checking anywhere that I am unaware of? Also, sound-theme-freedesktop has been blocking my build for a while. I see JaMa has a local commit, but I am not sure if that's the fix for the build failure we see in the report. Can someone provide tips on that nasty undefined macro? Thank you, Adam On Sat, Mar 29, 2014 at 5:28 PM, Martin Jansa wrote: > On Sat, Mar 29, 2014 at 11:54:32PM +0100, Martin Jansa wrote: > > On Wed, Mar 26, 2014 at 06:11:36PM +0100, Martin Jansa wrote: > > > On Sun, Mar 23, 2014 at 09:43:24PM +0100, Martin Jansa wrote: > > > > On Tue, Mar 18, 2014 at 07:50:08PM +0100, Martin Jansa wrote: > > > > > On Sat, Mar 15, 2014 at 03:10:46PM +0100, Martin Jansa wrote: > > > > > > On Tue, Mar 11, 2014 at 02:50:14PM +0100, Martin Jansa wrote: > > > > > > > On Tue, Mar 11, 2014 at 02:45:04PM +0100, Martin Jansa wrote: > > > > > > > > Biggest difference from last e-mail is aclocal changes which > can possibly explain > > > > > > > > increased number of do_configure failures, I've asked > Richard to delay merging B!=S > > > > > > > > change until we resolve or at least analyze these new > failures, so any help with > > > > > > > > would be highly appreciated. > > > > http://www.openembedded.org/wiki/Bitbake_World_Status > > > > == Failed tasks 2014-03-29 == > > Be aware that I plan to run test-dependencies script for next few days, > so changes to meta-oe will be delayed until it's finished and I can use > jenkins again to test incoming changes. > > If you want to do something really useful and you're not confident with > "big" changes, please scan qa.log files in URLs in report and send some > small patches to resolve unrecognized configure options (check the > configure > script if the option was replaced by something or if there is typo or if > it is applied by some bbclass which possibly shouldn't be used e.g. > gnome/gnombase). I offer beer on ELC for everybody who sends 10 changes > like this :). > > It won't show much, because a lot of recipes are still blocked by issues > listed bellow, but because release is close it's better to run it now > and fix at least found issues, before the release. > > I also have couple of local changes which I haven't sent yet, because > they aren't properly tested: > > f2e1f65 libgnomecanvas: add intltool dependency > cc3dac2 edbus: remove test-gui option > eff6aaa zram: include whole sysconfdir in PN > d308e37 atftp: include whole sysconfdir in PN > cdfd489 metacity: inherit only gnomebase > f415c1f gtksourceview2: inherit only gnomebase > 85550a0 goffice: inherit only gnomebase > 22a1a79 zenity: inherit only gnomebase > 29c844e gnome-themes: inherit only gnomebase > 561c24c gnome-backgrounds: inherit only gnomebase > 49fb47b gcr: inherit only gnomebase > b470935 modemmanager: inherit only gnomebase > bdc4cd9 libbonobo: inherit only gnomebase > 2b13d00 libgnome-keyring: inherit only gnomebase > fb2406f gnome-disk-utility: inherit only gnomebase > 58a1d87 libgdata: inherit only gnomebase > 6141925 libgtop: inherit only gnomebase > 8c021f1 gnome-bluetooth: inherit only gnomebase > 8723ea9 dconf: inherit only gnomebase > e63ca45 babl: inherit only gnomebase > bea1f1d gnome-menus: inherit only gnomebase > a33e667 wvstreams: fix QA warning > 7aa1b5e elementary: remove --disable-web > 6e3a7c8 libwnck*: inherit only gnomebase > 7855b14 tracker: inherit only gnomebase, fix QA warn > 3251a4e gnome-control-center: include datadir/mime in PN > 0ee66bb freerdp: move to nonworking > de68ce6 sound-theme-freedesktop: add glib-2.0 dependenecy > 5fac747 libdc1394: add libsdl dependency > 4609314 mplayer2: bump SRCREV to fix build issues with newer live555 > e403bec gvfs-gdu-volume-monitor: Define build dependency on > libgnome-keyring > > If you have some patches for issues bellow and you haven't sent them > because > you want to test them more, please send them with [WIP] in subject and I'll > include them in master-next for test-depedencies build (better to test > recipe > which is possibly broken in runtime than not testing it and it's > dependents at > all) > > I'll probably start it on Wed and last time it took 11 days. > > > === common (23) === > > * meta-openembedded/meta-gnome/recipes-gnome/devilspie/ > devilspie2_0.24.bb, do_compile > > * meta-openembedded/meta-gnome/recipes-gnome/libgnome/ > libgnomecanvas_2.30.3.bb, do_configure > > * meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/ > xbmc_git.bb,
[OE-core] [dora][PATCH] opkg-utils: Update to latest git master
From: Denys Dmytriyenko
The latest commit in opkg-utils allows packages created by opkg-build to be read
by dpkg-deb again.
(Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
but all of the update-alternative fixes from master are skipped)
Signed-off-by: Denys Dmytriyenko
Cc: Paul Barker
---
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 279cb74..fef0d13 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083"
RDEPENDS_${PN} = "python python-shell python-io python-math python-crypt
python-logging python-fcntl python-subprocess python-pickle python-compression
python-textutils python-stringold"
RDEPENDS_${PN}_class-native = ""
-SRCREV = "757a1664a440c60e8126443bf984e4bdf374c327"
+SRCREV = "c33b217016ee911718b10c9d57f9912935baf5a9"
PV = "0.1.8+git${SRCPV}"
SRC_URI = "git://git.yoctoproject.org/opkg-utils \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Bruce Ashfield : linux-yocto/3.10: fix drm build failure
On 2014-03-31, 5:51 PM, Martin Jansa wrote:
On Sun, Mar 30, 2014 at 10:36:53AM -0400, Bruce Ashfield wrote:
On 2014-03-30, 7:30 AM, Martin Jansa wrote:
On Sun, Mar 30, 2014 at 09:03:02AM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: 42c0eba4fac6b8bd28b58ec04574d04b0ab0c457
URL:
http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=42c0eba4fac6b8bd28b58ec04574d04b0ab0c457
Author: Bruce Ashfield
Date: Thu Mar 27 13:22:32 2014 -0400
linux-yocto/3.10: fix drm build failure
Andrea Adami reported the following build failure:
.../drm/drm_mm.h:105:2: error: implicit declaration of function
'BUG_ON' [-Werror=implicit-function-declaration]
| BUG_ON(!hole_node->hole_follows);
| ^
| CC drivers/pci/setup-res.o
| CC drivers/gpu/drm/i915/i915_drv.o
| cc1: some warnings being treated as errors
| make[6]: *** [drivers/gpu/drm/ttm/ttm_agp_backend.o] Error 1
| make[5]: *** [drivers/gpu/drm/ttm] Error 2
Cherry picking mainline commit 86e81f0e6 [drm/mm: include required headers in
drm_mm.h]
fixes the build problems.
cc: Andrea Adami
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_3.10.bb | 14 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
index 9b0c5d3..fe6773a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
@@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = "standard/preempt-rt/base"
KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
-SRCREV_machine ?= "f121a3aa028df37b8050779adaa239d29aaa2edd"
-SRCREV_machine_qemuppc ?= "7172d3cbc73584e724b61ef5d13fc3519720f4c0"
+SRCREV_machine ?= "f4351616572c6ad5a8b71b1becf02c3e779b85b8"
+SRCREV_machine_qemuppc ?= "a6dfc85e99633d739068a03d2551e39847628551"
SRCREV_meta ?= "df3aa753c8826127fb5ad811d56d57168551d6e4"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
index baa82fd..123f307 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
@@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.34"
KMETA = "meta"
-SRCREV_machine ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
+SRCREV_machine ?= "c7739be126930006e3bfbdb2fb070a967abc5e09"
SRCREV_meta ?= "df3aa753c8826127fb5ad811d56d57168551d6e4"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
index 56fbd07..49dd13d 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
@@ -11,13 +11,13 @@ KBRANCH_qemux86 = "standard/common-pc/base"
KBRANCH_qemux86-64 = "standard/common-pc-64/base"
KBRANCH_qemumips64 = "standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "e18e8c2c7cad913a25342f9f860fce24b8aa"
-SRCREV_machine_qemumips ?= "6f191aaecfdbebda450cec4a1f30fb0d1a2ed889"
-SRCREV_machine_qemuppc ?= "ba2e16160c7f910de432511ca0008101a7b2263b"
-SRCREV_machine_qemux86 ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
-SRCREV_machine_qemux86-64 ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
-SRCREV_machine_qemumips64 ?= "e05f0378e9c21d689eed8aacb306d2c1a044e0d0"
-SRCREV_machine ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
+SRCREV_machine_qemuarm ?= "0e99eabbe5b3bec853ace496f94612bc37800260"
+SRCREV_machine_qemumips ?= "b6b20f49e9a169a0672b7cc2d7b93d6652ca7873"
+SRCREV_machine_qemuppc ?= "d71b782615b802c78e1586494b94dd40531775c8"
+SRCREV_machine_qemux86 ?= "c7739be126930006e3bfbdb2fb070a967abc5e09"
Is it correct revision?
I can confirm that that is the right revision. I wonder what the fetcher
is doing, or is something in the infrastructure caching and older
revision ?
Sorry for noise, it was after all our mirror not getting updates
anymore, fetching it manually works.
No worries. Better to report and have me poke at it, then letting it sit.
It's not like I don't cross up SRCREVs periodically :(
Bruce
yow-bashfiel-d3 [/home/bruc...o-3.10.git]> git branch --contains
c7739be126930006e3bfbdb2fb070a967abc5e09
standard/arm-versatile-926ejs
standard/axxia/base
* standard/base
standard/beagleboard
standard/ck
standard/common-pc-64/base
standard/common-pc-64/chiefriver
standard/common-pc-64/crystalforest
standard/common-pc-64/jasperforest
standard/common-pc-64/rangeley
standard/common-pc-64/romley
standard/common-pc-64/sugarbay
standard/common-pc/atom-pc
standard/common-pc/b
Re: [OE-core] [PATCH 0/5] lnux-yocto: 3.14 updates
On Mon, Mar 31, 2014 at 5:09 PM, Bruce Ashfield wrote: > On Mon, Mar 31, 2014 at 1:56 PM, Bruce Ashfield > wrote: >> Richard/Saul, >> >> Here are the remaining changes from my previous pull request for linux-yocto >> updates. >> >> Now that 3.14 has been released, we have the full 3.14 kernel and associated >> libc-headers .. with no PV games. > > As a follow up to this, make sure that you have a clean sysroot when > building, we've > heard of a couple of perf build failures (again), that sound like the > header file issues > you'll see if an older kernel for a given machine is in the sysroot. replying to myself before I head out for food! The build of perf that broke here, was indeed a sysroot with 3.10 and 3.14 conflicting header files. My clean of the sysroot and a rebuild has worked. So I don't know of any reproducible perf build errors at the moment. Bruce > > I'm trying another build of qemux86 to see if I can duplicate any > issues, but won't > be around for a few hours to confirm or deny anything. > > Bruce > >> >> There is one new change in the libc-headers series, to adapt to the xz >> compression >> of new headers, but otherwise, it is the same as before. >> >> [ >>Subject: [PATCH 2/5] linux-libc-headers: make compression format >> configurable >> >>As of the 3.13 kernel bz2 compressed tarballs are not available. To >> support >>older header tarballs, and newer ones that require the 'xz' compressed >>bundles, we can break out a variable that allows versioned libc headers to >>select the archive format that works. >> >>Signed-off-by: Bruce Ashfield >> ] >> >> I've built and booted qemu* for this, so everything appears to be sane. >> >> Cheers, >> >> Bruce >> >> >> The following changes since commit 4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d: >> >> linux-yocto/3.10: fix qemuarm build failure (2014-03-30 23:53:00 +0100) >> >> are available in the git repository at: >> >> git://git.pokylinux.org/poky-contrib zedd/kernel >> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel >> >> Bruce Ashfield (5): >> linux-yocto/3.14: introduce versioned recipes >> linux-libc-headers: make compression format configurable >> linux-libc-headers: add 3.14 libc headers >> libc-headers: set TC default to 3.14 >> linux-libc-headers: remove 3.10 recipe >> >> meta/conf/distro/include/tcmode-default.inc| 2 +- >> .../linux-libc-headers/linux-libc-headers.inc | 4 +- >> ...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 -- >> ...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 - >> ...efile.headersinst-install-headers-from-sc.patch | 59 >> -- >> .../linux-libc-headers/linux-libc-headers_3.10.bb | 11 >> .../linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++ >> meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21 >> meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++ >> 9 files changed, 69 insertions(+), 156 deletions(-) >> delete mode 100644 >> meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch >> delete mode 100644 >> meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch >> delete mode 100644 >> meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch >> delete mode 100644 >> meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb >> create mode 100644 >> meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb >> create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb >> create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb >> >> -- >> 1.8.1.2 >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end" -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] pixbufcache.bbclass: Fix setscene silent failures
Unfortunately gdk-pixbuf-query-loaders can issue errors but still return
success. We therefore check for output and error in the case any output
is issued (normal success does not issue any).
Signed-off-by: Richard Purdie
---
Ross: I'm open to better patches ;-)
[I wrote this to debug other problems]
diff --git a/meta/classes/pixbufcache.bbclass b/meta/classes/pixbufcache.bbclass
index 414fd30..88da734 100644
--- a/meta/classes/pixbufcache.bbclass
+++ b/meta/classes/pixbufcache.bbclass
@@ -53,7 +53,11 @@ SSTATEPOSTINSTFUNCS_append_class-native = "
pixbufcache_sstate_postinst"
pixbufcache_sstate_postinst() {
if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" =
"populate_sysroot_setscene" ]
then
- gdk-pixbuf-query-loaders --update-cache
+ T=`gdk-pixbuf-query-loaders --update-cache 2>&1`
+ if [ -n "$T" ]; then
+ echo $T
+ exit 1
+ fi
fi
}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Bruce Ashfield : linux-yocto/3.10: fix drm build failure
On Sun, Mar 30, 2014 at 10:36:53AM -0400, Bruce Ashfield wrote:
> On 2014-03-30, 7:30 AM, Martin Jansa wrote:
> > On Sun, Mar 30, 2014 at 09:03:02AM +, g...@git.openembedded.org wrote:
> >> Module: openembedded-core.git
> >> Branch: master
> >> Commit: 42c0eba4fac6b8bd28b58ec04574d04b0ab0c457
> >> URL:
> >> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=42c0eba4fac6b8bd28b58ec04574d04b0ab0c457
> >>
> >> Author: Bruce Ashfield
> >> Date: Thu Mar 27 13:22:32 2014 -0400
> >>
> >> linux-yocto/3.10: fix drm build failure
> >>
> >> Andrea Adami reported the following build failure:
> >>
> >> .../drm/drm_mm.h:105:2: error: implicit declaration of function
> >> 'BUG_ON' [-Werror=implicit-function-declaration]
> >> | BUG_ON(!hole_node->hole_follows);
> >> | ^
> >> | CC drivers/pci/setup-res.o
> >> | CC drivers/gpu/drm/i915/i915_drv.o
> >> | cc1: some warnings being treated as errors
> >> | make[6]: *** [drivers/gpu/drm/ttm/ttm_agp_backend.o] Error 1
> >> | make[5]: *** [drivers/gpu/drm/ttm] Error 2
> >>
> >> Cherry picking mainline commit 86e81f0e6 [drm/mm: include required headers
> >> in drm_mm.h]
> >> fixes the build problems.
> >>
> >> cc: Andrea Adami
> >> Signed-off-by: Bruce Ashfield
> >>
> >> ---
> >>
> >> meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb | 4 ++--
> >> meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb | 2 +-
> >> meta/recipes-kernel/linux/linux-yocto_3.10.bb | 14 +++---
> >> 3 files changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> >> b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> >> index 9b0c5d3..fe6773a 100644
> >> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> >> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> >> @@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
> >> KBRANCH = "standard/preempt-rt/base"
> >> KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
> >>
> >> -SRCREV_machine ?= "f121a3aa028df37b8050779adaa239d29aaa2edd"
> >> -SRCREV_machine_qemuppc ?= "7172d3cbc73584e724b61ef5d13fc3519720f4c0"
> >> +SRCREV_machine ?= "f4351616572c6ad5a8b71b1becf02c3e779b85b8"
> >> +SRCREV_machine_qemuppc ?= "a6dfc85e99633d739068a03d2551e39847628551"
> >> SRCREV_meta ?= "df3aa753c8826127fb5ad811d56d57168551d6e4"
> >>
> >> SRC_URI =
> >> "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
> >> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
> >> b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
> >> index baa82fd..123f307 100644
> >> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
> >> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
> >> @@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.34"
> >>
> >> KMETA = "meta"
> >>
> >> -SRCREV_machine ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
> >> +SRCREV_machine ?= "c7739be126930006e3bfbdb2fb070a967abc5e09"
> >> SRCREV_meta ?= "df3aa753c8826127fb5ad811d56d57168551d6e4"
> >>
> >> PV = "${LINUX_VERSION}+git${SRCPV}"
> >> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
> >> b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
> >> index 56fbd07..49dd13d 100644
> >> --- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
> >> +++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
> >> @@ -11,13 +11,13 @@ KBRANCH_qemux86 = "standard/common-pc/base"
> >> KBRANCH_qemux86-64 = "standard/common-pc-64/base"
> >> KBRANCH_qemumips64 = "standard/mti-malta64"
> >>
> >> -SRCREV_machine_qemuarm ?= "e18e8c2c7cad913a25342f9f860fce24b8aa"
> >> -SRCREV_machine_qemumips ?= "6f191aaecfdbebda450cec4a1f30fb0d1a2ed889"
> >> -SRCREV_machine_qemuppc ?= "ba2e16160c7f910de432511ca0008101a7b2263b"
> >> -SRCREV_machine_qemux86 ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
> >> -SRCREV_machine_qemux86-64 ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
> >> -SRCREV_machine_qemumips64 ?= "e05f0378e9c21d689eed8aacb306d2c1a044e0d0"
> >> -SRCREV_machine ?= "2ee37bfe732c73f7d39af55875ce8d30b282471c"
> >> +SRCREV_machine_qemuarm ?= "0e99eabbe5b3bec853ace496f94612bc37800260"
> >> +SRCREV_machine_qemumips ?= "b6b20f49e9a169a0672b7cc2d7b93d6652ca7873"
> >> +SRCREV_machine_qemuppc ?= "d71b782615b802c78e1586494b94dd40531775c8"
> >> +SRCREV_machine_qemux86 ?= "c7739be126930006e3bfbdb2fb070a967abc5e09"
> >
> > Is it correct revision?
> >
>
> I can confirm that that is the right revision. I wonder what the fetcher
> is doing, or is something in the infrastructure caching and older
> revision ?
Sorry for noise, it was after all our mirror not getting updates
anymore, fetching it manually works.
> yow-bashfiel-d3 [/home/bruc...o-3.10.git]> git branch --contains
> c7739be126930006e3bfbdb2fb070a967abc5e09
>standard/arm-versatile-926ejs
>standard/axxia/base
> * standard/base
>standard/beagleboard
>standard/ck
>standard/common-pc-64/base
>standard/common-pc-64/c
Re: [OE-core] [PATCH 1/1] util-linux-native: fix qsort_r for CentOS 5.10
On 26 March 2014 07:01, Robert Yang wrote:
> The qsort_r() was added to glibc in version 2.8, so there is no qsort_r() on
> the host like CentOS 5.x, use qsort() to fix it since they are nearly
> identical.
>
> Signed-off-by: Robert Yang
> ---
> .../util-linux/util-linux-native-qsort.patch | 34
>
> meta/recipes-core/util-linux/util-linux_2.24.1.bb |4 ++-
> 2 files changed, 37 insertions(+), 1 deletion(-)
> create mode 100644
> meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
>
> diff --git
> a/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
> b/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
> new file mode 100644
> index 000..1707683
> --- /dev/null
> +++ b/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
> @@ -0,0 +1,34 @@
> +From f220d809be1baa654503bf6ff52f3630b0d7015c Mon Sep 17 00:00:00 2001
> +From: Robert Yang
> +Date: Wed, 26 Mar 2014 01:30:29 +
> +Subject: [PATCH] sun.c: use qsort() to instead of qsort_r()
> +
> +qsort_r() was added to glibc in version 2.8, so there is no qsort_r() on
> +the host like CentOS 5.x.
> +
> +Upstream-Status: Inappropriate [Other]
> +
> +Signed-off-by: Robert Yang
> +---
> + libfdisk/src/sun.c | 5 ++---
> + 1 file changed, 2 insertions(+), 3 deletions(-)
> +
> +diff --git a/libfdisk/src/sun.c b/libfdisk/src/sun.c
> +index e73c701..f7899ec 100644
> +--- a/libfdisk/src/sun.c
> b/libfdisk/src/sun.c
> +@@ -427,9 +427,8 @@ static int sun_verify_disklabel(struct fdisk_context
> *cxt)
> + else
> + array[i] = -1;
> + }
> +-qsort_r(array,ARRAY_SIZE(array),sizeof(array[0]),
> +-(int (*)(const void *,const void *,void *)) verify_sun_cmp,
> +-verify_sun_starts);
> ++qsort(array,ARRAY_SIZE(array),sizeof(array[0]),
> ++(int (*)(const void *,const void *)) verify_sun_cmp);
I've just been looking at this for building util-linux on top of musl
(as musl-libc doesn't implement qsort_r)
and my solution was to import a qsort_r implementation from ccl
(https://ccl.googlecode.com/svn/trunk/qsort_r.c).
Are you sure this solution works? verify_sun_cmp takes 3 parameters
not 2 and it uses the 3rd parameter (data). From reading this I'd
imagine a segfault is likely to occur in verify_sun_cmp if qsort is
used instead of qsort_r.
> +
> + if (array[0] == -1) {
> + fdisk_info(cxt, _("No partitions defined."));
> +--
> +1.8.2.1
> +
> diff --git a/meta/recipes-core/util-linux/util-linux_2.24.1.bb
> b/meta/recipes-core/util-linux/util-linux_2.24.1.bb
> index aa98b65..ab80ab6 100644
> --- a/meta/recipes-core/util-linux/util-linux_2.24.1.bb
> +++ b/meta/recipes-core/util-linux/util-linux_2.24.1.bb
> @@ -4,7 +4,9 @@ require util-linux.inc
> # To support older hosts, we need to patch and/or revert
> # some upstream changes. Only do this for native packages.
> OLDHOST = ""
> -OLDHOST_class-native = "file://util-linux-native.patch"
> +OLDHOST_class-native = "file://util-linux-native.patch \
> +file://util-linux-native-qsort.patch \
> + "
>
> SRC_URI += "file://util-linux-ng-replace-siginterrupt.patch \
> file://util-linux-ng-2.16-mount_lock_path.patch \
> --
> 1.7.10.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Thanks,
--
Paul Barker
Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] lnux-yocto: 3.14 updates
On Mon, Mar 31, 2014 at 1:56 PM, Bruce Ashfield wrote: > Richard/Saul, > > Here are the remaining changes from my previous pull request for linux-yocto > updates. > > Now that 3.14 has been released, we have the full 3.14 kernel and associated > libc-headers .. with no PV games. As a follow up to this, make sure that you have a clean sysroot when building, we've heard of a couple of perf build failures (again), that sound like the header file issues you'll see if an older kernel for a given machine is in the sysroot. I'm trying another build of qemux86 to see if I can duplicate any issues, but won't be around for a few hours to confirm or deny anything. Bruce > > There is one new change in the libc-headers series, to adapt to the xz > compression > of new headers, but otherwise, it is the same as before. > > [ >Subject: [PATCH 2/5] linux-libc-headers: make compression format > configurable > >As of the 3.13 kernel bz2 compressed tarballs are not available. To support >older header tarballs, and newer ones that require the 'xz' compressed >bundles, we can break out a variable that allows versioned libc headers to >select the archive format that works. > >Signed-off-by: Bruce Ashfield > ] > > I've built and booted qemu* for this, so everything appears to be sane. > > Cheers, > > Bruce > > > The following changes since commit 4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d: > > linux-yocto/3.10: fix qemuarm build failure (2014-03-30 23:53:00 +0100) > > are available in the git repository at: > > git://git.pokylinux.org/poky-contrib zedd/kernel > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel > > Bruce Ashfield (5): > linux-yocto/3.14: introduce versioned recipes > linux-libc-headers: make compression format configurable > linux-libc-headers: add 3.14 libc headers > libc-headers: set TC default to 3.14 > linux-libc-headers: remove 3.10 recipe > > meta/conf/distro/include/tcmode-default.inc| 2 +- > .../linux-libc-headers/linux-libc-headers.inc | 4 +- > ...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 -- > ...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 - > ...efile.headersinst-install-headers-from-sc.patch | 59 > -- > .../linux-libc-headers/linux-libc-headers_3.10.bb | 11 > .../linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++ > meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21 > meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++ > 9 files changed, 69 insertions(+), 156 deletions(-) > delete mode 100644 > meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch > delete mode 100644 > meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch > delete mode 100644 > meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch > delete mode 100644 > meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb > create mode 100644 > meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb > create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb > create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb > > -- > 1.8.1.2 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Mon, Mar 31, 2014 at 12:10 PM, Martin Jansa wrote:
> On Mon, Mar 31, 2014 at 10:20:49PM +0800, Kai Kang wrote:
>> From: Roy Li
>>
>> When native package is built, use the uname to return the kernel version.
>>
>> When target is built, read kernel version from
>> ${STAGING_KERNEL_DIR}/kernel-abiversion
>> to avoid to use the hardcode kernel version.
>
> Doesn't it make nss MACHINE_ARCH like most virtual/kernel providers are?
Yes.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OE Changelog since 2014-03-23 until 2014-03-30
Changelog since 2014-03-23 until 2014-03-30. Projects included in this report: bitbake: git://git.openembedded.org/bitbake openembedded-core: git://git.openembedded.org/openembedded-core meta-openembedded: git://git.openembedded.org/meta-openembedded meta-angstrom: git://github.com/Angstrom-distribution/meta-angstrom.git meta-arago: git://arago-project.org/git/meta-arago.git meta-beagleboard: git://github.com/beagleboard/meta-beagleboard.git meta-browser: git://github.com/OSSystems/meta-browser.git meta-bug: git://github.com/buglabs/meta-bug.git meta-chicken: git://github.com/OSSystems/meta-chicken meta-efikamx: git://github.com/kraj/meta-efikamx.git meta-ettus: http://github.com/koenkooi/meta-ettus.git meta-fsl-arm: git://git.yoctoproject.org/meta-fsl-arm meta-fsl-arm-extra: git://github.com/Freescale/meta-fsl-arm-extra.git meta-fsl-ppc: git://git.yoctoproject.org/meta-fsl-ppc meta-guacamayo: git://github.com/Guacamayo/meta-guacamayo.git meta-gumstix: git://github.com/gumstix/meta-gumstix.git meta-gumstix-community: git://gitorious.org/schnitzeltony-oe-meta/meta-gumstix-community.git meta-handheld: git://git.openembedded.org/meta-handheld meta-igep: http://github.com/ebutera/meta-igep.git meta-intel: git://git.yoctoproject.org/meta-intel meta-ivi: git://git.yoctoproject.org/meta-ivi meta-java: git://github.com/woglinde/meta-java meta-kde: git://gitorious.org/openembedded-core-layers/meta-kde.git meta-micro: git://git.openembedded.org/meta-micro meta-mono: git://git.yoctoproject.org/meta-mono.git meta-netbookpro: git://github.com/tworaz/meta-netbookpro meta-nslu2: git://github.com/kraj/meta-nslu2 meta-opie: git://git.openembedded.org/meta-opie meta-qt3: git://git.yoctoproject.org/meta-qt3 meta-qt5: git://github.com/meta-qt5/meta-qt5.git meta-slugos: git://github.com/kraj/meta-slugos meta-systemd: git://git.yoctoproject.org/meta-systemd meta-raspberrypi: git://github.com/djwillis/meta-raspberrypi.git meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git meta-ti: git://git.yoctoproject.org/meta-ti meta-webos: git://github.com/openwebos/meta-webos.git meta-xilinx: git://git.yoctoproject.org/meta-xilinx meta-yocto: git://git.yoctoproject.org/meta-yocto openembedded: git://git.openembedded.org/openembedded Changelog for bitbake: Alexandru DAMIAN (6): toaster: Revert "added file types to the Outputs column in the build page" toaster: select recipe based on PN name toasterui: save missed sstate tasks toaster: clean exit on bb server shutdown toaster: replace package dependency tag w/ view queries bitbake: toaster: do not trap SIGCHLD Amit Kumar Chaudhary (1): toaster: combine ready functions Belen Barros Pena (10): toaster: Change objectname 'packages' to 'packages built' toaster: Fix alignment issue in searchform toaster: Add help text to filters toaster: Update local configuration counter toaster: Change "0 found" to "No found" toaster: Change placeholder attribute in variables table toaster: Remove commented-out code from views.py toaster: Fix help text typos toaster: Small fixes in tasks UI toaster: Fix typo in heading code Cristiana Voicu (1): bitbake toaster: check the file_name with the content of the IMAGE_FSTYPES v Dave Lerner (4): toaster: fix package size 1st sort order toaster: format packages with size = -1 toaster: show installed package name toaster: fix dirinfo empty dir expansion David Reyna (9): toaster: warn new filter replaces existing filter toaster: reset default filter for configvar page on new searches toaster: add search by section to all recipe page toaster: add Image detail and multiple targets to dashboard toaster: blocks for custom/highlighted navigation and breadcrumb links toaster: insure _get_query returns distinct records toaster: add support for empty states in pages toaster: added file types to the Outputs column in the build toaster: filter tasks with cache attempts for all attempts Irina Patru (1): toaster: Remove circular dependecies from packages/recipes Marius Avram (4): hob: output filenames based on initial recipe name toaster: apply filter only on selected attributes cooker: delVar in removeConfigurationVar hob: fix set_extra_setting function Olof Johansson (5): fetch2.URI: Coerce urlparse to use netloc for all schemes tests.fetch: Remove debug assert fetch2.URI: add support for query parameters fetch2.URI: Support URIs with both query strings and params fetch2.URI: Set username/password should not change the other Richard Purdie (15): runqueue: Fix sceneQueueEvent to use the correct hashes test/data: Add in test for append/prepend/remove override operations data_smart: Fix caching issue for double remove references bitbake: Force -S option to take a parameter runqueue/siggen: Pass in commandline options to dump_sigs() cooker/event: Overhaul sanity test mechanism msg: Add stdout/stderr filters
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On 14-03-31 03:47 PM, Khem Raj wrote: -Khem On Mar 31, 2014 12:33 PM, "Bruce Ashfield" mailto:bruce.ashfi...@windriver.com>> wrote: > > On 14-03-31 03:29 PM, Khem Raj wrote: >> >> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield >> mailto:bruce.ashfi...@windriver.com>> wrote: >>> >>> >>> -LINUXLIBCVERSION ?= "3.10" >>> +LINUXLIBCVERSION ?= "3.14" >> >> >> Does this buy us much ? Infact its too late to change usespace APIs > > > This was always the plan. I've been building with all the 3.14 -rc > headers for ages .. and as we've talked about in the past, we always > will update them to the newest kernel in any release. well i think its good to update them however may be some components should be given enough soak time and kernel headers are one of such pieces since its effects are across layers and they will start testing them now. To be fair, we've had the -dev kernel and headers available for over a month now. This is also my second send of this series, so it isn't like this hasn't been available or broadcast. People noticing it now, or being busy, isn't something I can directly control. > > They are compatible with 3.10, and I've tested the combinations of > old kernels, new libc and new kernels with the new libc interfaces. i dont believe you tested all layer combinations I've tested everything I can, as has the autobuilder. I can't offer any more than this. > > >> at this point. 3.10 being LTS >> I would assume its a better option to keep at 3.10 > > > I disagree, this is consistent with other releases and the documented > plan of action. I'd rather not have a massive version jump in the fall. its probably not a bad option to stick to LTS version for kernel headers after all Again, I disagree. We can maybe keep the 3.10 recipe around, but the default should be 3.14, we need a matched kernel and libc-headers to get the best integration and leveraging of the latest features. If we pull the headers, pull the kernel. Bruce > > Sure 3.14 slipping out by a few weeks upstream was a problem, but its > not like we haven't been testing with it. > > Bruce > >> > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
-Khem On Mar 31, 2014 12:33 PM, "Bruce Ashfield" wrote: > > On 14-03-31 03:29 PM, Khem Raj wrote: >> >> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield >> wrote: >>> >>> >>> -LINUXLIBCVERSION ?= "3.10" >>> +LINUXLIBCVERSION ?= "3.14" >> >> >> Does this buy us much ? Infact its too late to change usespace APIs > > > This was always the plan. I've been building with all the 3.14 -rc > headers for ages .. and as we've talked about in the past, we always > will update them to the newest kernel in any release. well i think its good to update them however may be some components should be given enough soak time and kernel headers are one of such pieces since its effects are across layers and they will start testing them now. > > They are compatible with 3.10, and I've tested the combinations of > old kernels, new libc and new kernels with the new libc interfaces. i dont believe you tested all layer combinations > > >> at this point. 3.10 being LTS >> I would assume its a better option to keep at 3.10 > > > I disagree, this is consistent with other releases and the documented > plan of action. I'd rather not have a massive version jump in the fall. its probably not a bad option to stick to LTS version for kernel headers after all > > Sure 3.14 slipping out by a few weeks upstream was a problem, but its > not like we haven't been testing with it. > > Bruce > >> > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes
On 14-03-31 03:39 PM, Paul Barker wrote: On 31 March 2014 18:56, Bruce Ashfield wrote: The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce the versioned recipes here. Should this say Yocto 1.6? Ha. Yes it should! Bruce -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes
On 31 March 2014 18:56, Bruce Ashfield wrote: > The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce > the versioned recipes here. > Should this say Yocto 1.6? -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On 14-03-31 03:29 PM, Khem Raj wrote: On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield wrote: -LINUXLIBCVERSION ?= "3.10" +LINUXLIBCVERSION ?= "3.14" Does this buy us much ? Infact its too late to change usespace APIs This was always the plan. I've been building with all the 3.14 -rc headers for ages .. and as we've talked about in the past, we always will update them to the newest kernel in any release. They are compatible with 3.10, and I've tested the combinations of old kernels, new libc and new kernels with the new libc interfaces. at this point. 3.10 being LTS I would assume its a better option to keep at 3.10 I disagree, this is consistent with other releases and the documented plan of action. I'd rather not have a massive version jump in the fall. Sure 3.14 slipping out by a few weeks upstream was a problem, but its not like we haven't been testing with it. Bruce -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield wrote: > > -LINUXLIBCVERSION ?= "3.10" > +LINUXLIBCVERSION ?= "3.14" Does this buy us much ? Infact its too late to change usespace APIs at this point. 3.10 being LTS I would assume its a better option to keep at 3.10 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On Mon, Mar 31, 2014 at 12:21 PM, Paul Barker wrote: > On 30 March 2014 17:48, Khem Raj wrote: >> On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: >>> On 30 March 2014 05:17, Khem Raj wrote: On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: > On 26 March 2014 22:12, Burton, Ross wrote: >> On 26 March 2014 22:04, Khem Raj wrote: >>> There were interest in other threads in having musl as an alternative >>> to eglibc/uclibc that we already have in OE, in that direction I have >>> poured in my on and off work and put it into a contrib tree >> >> Blimey Khem that was quick. :) >> > > Agreed! > > I wonder if it's worth splitting this out into its own layer though I thought about it and since class/conf changes that need to go in into OE-core first I kept it as it is (lazyness too). I think once the core support is available in OE-core we can spin the recipes into a layer of its own. > (with fixes done via bbappends) so that it's easy for multiple people > to contribute to. It would also mean it doesn't need rebasing onto > master all the time. > > I'd definitely like to get involved with this. In particular I can > ensure opkg (both current release and development branch) work with > musl and see if some of my preferred software from meta-oe will build > (vim, htop, etc). start with what we have. Once master opens up I would propose the needed changes to OE-core and spin a layer >>> >>> I did a quick 'bitbake -k core-image-minimal' to see what's currently >>> failing. Full logs and config at >>> http://www.paulbarker.me.uk/musl-build/ >>> >>> Build Configuration: >>> BB_VERSION= "1.21.1" >>> BUILD_SYS = "x86_64-linux" >>> NATIVELSBSTRING = "Ubuntu-12.04" >>> TARGET_SYS= "arm-oe-linux-musleabi" >>> MACHINE = "qemuarm" >>> DISTRO= "nodistro" >>> DISTRO_VERSION= "nodistro.0" >>> TUNE_FEATURES = "armv5 thumb dsp" >>> TARGET_FPU= "soft" >>> meta = "kraj/musl:faafa7022ed057d55c131c456d1bdd5dfa3d2517" >>> >>> Summary: 6 tasks failed: >>> openembedded-core/meta/recipes-support/attr/attr_2.4.47.bb, do_compile >>> openembedded-core/meta/recipes-devtools/python/python_2.7.3.bb, do_compile >>> openembedded-core/meta/recipes-core/util-linux/util-linux_2.24.1.bb, >>> do_compile >>> openembedded-core/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb, >>> do_compile >>> openembedded-core/meta/recipes-core/busybox/busybox_1.22.1.bb, do_compile >>> openembedded-core/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb, >>> do_compile >>> >>> I can see for util-linux that we need to implement qsort_r(). >>> >>> Busybox probably just needs config changes: >>> http://wiki.musl-libc.org/wiki/Building_Busybox >> >> >> I already have local fix for busy box. > > Excellent! I'm currently looking at util-linux. > > I think we should ask for a new repo to be setup on > git.yoctoproject.org for meta-musl. I'm happy to be one of the > maintainers for that, I hope that you are as well and maybe a couple > of the others who were interested could also help. I think having a > few people as maintainers is important as we're all already fairly > busy on other projects. > > Once the layer is setup we can move the recipes off your branch of > oe-core and into the layer as time permits. That would just leave the > changes which need to go into oe-core on your branch. > > Does that sound like a sensible plan? I think it does; this allow for easy sharing of work and do increase its visibility. So I agree with the plan and goal. I will try to help on this as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] linux-libc-headers: make compression format configurable
As of the 3.13 kernel bz2 compressed tarballs are not available. To support
older header tarballs, and newer ones that require the 'xz' compressed
bundles, we can break out a variable that allows versioned libc headers to
select the archive format that works.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 3f27afa4c922..b18d09fd6c3e 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -41,7 +41,9 @@ python __anonymous () {
inherit kernel-arch
-SRC_URI =
"${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.bz2"
+KORG_ARCHIVE_COMPRESSION ?= "bz2"
+
+SRC_URI =
"${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}"
S = "${WORKDIR}/linux-${PV}"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] linux-libc-headers: remove 3.10 recipe
3.14 is now the reference for libc-headers. After building and booting 3.x based
BSPs against the 3.14 headers, we can safely remove the old version and patches
that are now part of the mainline kernel.
Signed-off-by: Bruce Ashfield
---
...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 --
...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 -
...efile.headersinst-install-headers-from-sc.patch | 59 --
.../linux-libc-headers/linux-libc-headers_3.10.bb | 11
4 files changed, 154 deletions(-)
delete mode 100644
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch
delete mode 100644
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch
delete mode 100644
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch
delete mode 100644
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb
diff --git
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch
deleted file mode 100644
index da2e117a486d..
---
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch
+++ /dev/null
@@ -1,50 +0,0 @@
-From 7dddfb8fec5317ea16154d30e8e18b6559979b60 Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield
-Date: Sun, 25 Aug 2013 22:51:07 -0400
-Subject: [PATCH] ptrace.h: remove ptrace_peeksiginfo_args
-
-The addition of ptrace_peeksiginfo_args to the uapi in kernel commit
-84c751bd [ptrace: add ability to retrieve signals without removing from a
queue (v4)]
-means that existing applications using glibc versions that define
ptrace_peeksiginfo_args
-in sys/ptrace.h will get duplicate structure definitions like:
-
-| In file included from
/poky-master/build/tmp/work/i586-poky-linux/strace/4.8-r0/strace-4.8/process.c:66:0:
-| /poky-master/build/tmp/sysroots/qemux86/usr/include/linux/ptrace.h:58:8:
error: redefinition of 'struct ptrace_peeksiginfo_args'
-| struct ptrace_peeksiginfo_args {
-| ^
-| In file included from
/poky-master/build/tmp/work/i586-poky-linux/strace/4.8-r0/strace-4.8/defs.h:159:0,
-| from
/poky-master/build/tmp/work/i586-poky-linux/strace/4.8-r0/strace-4.8/process.c:37:
-| /poky-master/build/tmp/sysroots/qemux86/usr/include/sys/ptrace.h:191:8:
note: originally defined here
-| struct ptrace_peeksiginfo_args
-| ^
-| make[2]: *** [process.o] Error 1
-
-Reverting to the previous status of not exporting this structure temporarily
-fixes applications, until they can be adjusted to not mix sys/ptrace.h and
-linux/ptrace.h includes.
-
-Signed-off-by: Bruce Ashfield
- include/uapi/linux/ptrace.h |6 --
- 1 file changed, 6 deletions(-)
-
-diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
-index 52ebcc8..524599d 100644
a/include/uapi/linux/ptrace.h
-+++ b/include/uapi/linux/ptrace.h
-@@ -55,12 +55,6 @@
-
- #define PTRACE_PEEKSIGINFO0x4209
-
--struct ptrace_peeksiginfo_args {
-- __u64 off; /* from which siginfo to start */
-- __u32 flags;
-- __s32 nr; /* how may siginfos to take */
--};
--
- /* Read signals from a shared (process wide) queue */
- #define PTRACE_PEEKSIGINFO_SHARED (1 << 0)
-
---
-1.7.10.4
-
diff --git
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch
deleted file mode 100644
index 1bf0e7ec85f0..
---
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From c0f8bd146a8b3e630798561c605f5669823107af Mon Sep 17 00:00:00 2001
-From: Aurelien Jarno
-Date: Thu, 14 Nov 2013 15:16:19 +1100
-Subject: [PATCH] UAPI: include in linux/raid/md_p.h
-
-linux/raid/md_p.h is using conditionals depending on endianess and fails
-with an error if neither of __BIG_ENDIAN, __LITTLE_ENDIAN or
-__BYTE_ORDER are defined, but it doesn't include any header which can
-define these constants. This make this header unusable alone.
-
-This patch adds a #include at the beginning of this
-header to make it usable alone. This is needed to compile klibc on MIPS.
-
-Signed-off-by: Aurelien Jarno
-Signed-off-by: NeilBrown
- include/uapi/linux/raid/md_p.h | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h
-index fe1a540..f7cf7f3 100644
a/include/uapi/linux/raid/md_p.h
-+++ b/include/uapi/linux/raid/md_p.h
-@@ -16,6 +16,7 @@
- #define _MD_P_H
-
[OE-core] [PATCH 3/5] linux-libc-headers: add 3.14 libc headers
Introduce the 3.14 linux-libc-headers recipe, now that the 3.14 kernel is available, and the default for the qemu reference BSPs. The three patches which were required for the previous 3.10 libc-headers are not required for 3.14 and can be ignored. Signed-off-by: Bruce Ashfield --- meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb new file mode 100644 index ..9ac70af942a1 --- /dev/null +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb @@ -0,0 +1,7 @@ +KORG_ARCHIVE_COMPRESSION = "xz" + +require linux-libc-headers.inc + +SRC_URI[md5sum] = "b621207b3f6ecbb67db18b13258f8ea8" +SRC_URI[sha256sum] = "61558aa490855f42b6340d1a1596be47454909629327c49a5e4e10268065dffa" + -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
On 3/31/14, 12:31 PM, Burton, Ross wrote: On 31 March 2014 18:03, Richard Purdie wrote: I kind of disagree with that, the LSB image can take into account configuration in other parts of the system. If pam isn't configured, I'm not sure that should automatically make it completely unbuildable... An image that claims to be LSB compliant but due to not-immediately-obvious DISTRO_FEATURES isn't actually doesn't seem like a good idea to me, fwiw. If the LSB image requires PAM, X11 and so on then it should require the features. I agree the image with the name LSB should enforce the items it knows the LSB depends on. If the user patches that away then it becomes their issue. --Mark Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
Signed-off-by: Bruce Ashfield
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index d6a626cfab8c..300deeaf5fb9 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -22,7 +22,7 @@ SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.24"
EGLIBCVERSION ?= "2.19"
UCLIBCVERSION ?= "0.9.33+git%"
-LINUXLIBCVERSION ?= "3.10"
+LINUXLIBCVERSION ?= "3.14"
PREFERRED_VERSION_gcc ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-cross ?= "${GCCVERSION}"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] lnux-yocto: 3.14 updates
Richard/Saul, Here are the remaining changes from my previous pull request for linux-yocto updates. Now that 3.14 has been released, we have the full 3.14 kernel and associated libc-headers .. with no PV games. There is one new change in the libc-headers series, to adapt to the xz compression of new headers, but otherwise, it is the same as before. [ Subject: [PATCH 2/5] linux-libc-headers: make compression format configurable As of the 3.13 kernel bz2 compressed tarballs are not available. To support older header tarballs, and newer ones that require the 'xz' compressed bundles, we can break out a variable that allows versioned libc headers to select the archive format that works. Signed-off-by: Bruce Ashfield ] I've built and booted qemu* for this, so everything appears to be sane. Cheers, Bruce The following changes since commit 4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d: linux-yocto/3.10: fix qemuarm build failure (2014-03-30 23:53:00 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (5): linux-yocto/3.14: introduce versioned recipes linux-libc-headers: make compression format configurable linux-libc-headers: add 3.14 libc headers libc-headers: set TC default to 3.14 linux-libc-headers: remove 3.10 recipe meta/conf/distro/include/tcmode-default.inc| 2 +- .../linux-libc-headers/linux-libc-headers.inc | 4 +- ...1-ptrace.h-remove-ptrace_peeksiginfo_args.patch | 50 -- ...lude-asm-byteorder.h-in-linux-raid-md_p.h.patch | 34 - ...efile.headersinst-install-headers-from-sc.patch | 59 -- .../linux-libc-headers/linux-libc-headers_3.10.bb | 11 .../linux-libc-headers/linux-libc-headers_3.14.bb | 7 +++ meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21 meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++ 9 files changed, 69 insertions(+), 156 deletions(-) delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-ptrace.h-remove-ptrace_peeksiginfo_args.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/UAPI-include-asm-byteorder.h-in-linux-raid-md_p.h.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch delete mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.10.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index ..2e142bfd9029
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -0,0 +1,21 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = "standard/tiny/base"
+LINUX_KERNEL_TYPE = "tiny"
+KCONFIG_MODE = "--allnoconfig"
+
+LINUX_VERSION ?= "3.14"
+
+KMETA = "meta"
+
+SRCREV_machine ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0"
+SRCREV_meta ?= "fc8c30398dbc3cdea787a1042242d4aab689d0ae"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
+
+COMPATIBLE_MACHINE = "(qemux86)"
+
+# Functionality flags
+KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
new file mode 100644
index ..d5202cd4391a
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -0,0 +1,37 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = "standard/base"
+
+# board specific branches
+KBRANCH_qemuarm = "standard/arm-versatile-926ejs"
+KBRANCH_qemumips = "standard/mti-malta32"
+KBRANCH_qemuppc = "standard/qemuppc"
+KBRANCH_qemux86 = "standard/common-pc/base"
+KBRANCH_qemux86-64 = "standard/common-pc-64/base"
+KBRANCH_qemumips64 = "standard/mti-malta64"
+
+SRCREV_machine_qemuarm ?= "c966987f88a0ee5753c3dee87e7a962d0cad5376"
+SRCREV_machine_qemumips ?= "61811c215c601ee96ccbf79333bbc73482b0f017"
+SRCREV_machine_qemuppc ?= "0d5cf5e938f4e6d3c6a398e98c8ece3ce05539f7"
+SRCREV_machine_qemux86 ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0"
+SRCREV_machine_qemux86-64 ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0"
+SRCREV_machine_qemumips64 ?= "ccb2a788551a7951563ac44a27175c6f28501008"
+SRCREV_machine ?= "0143c6ebb4a2d63b241df5f608b19f483f7eb9e0"
+SRCREV_meta ?= "fc8c30398dbc3cdea787a1042242d4aab689d0ae"
+
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
+
+LINUX_VERSION ?= "3.14"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+KMETA = "meta"
+
+COMPATIBLE_MACHINE = "qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
+KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
+KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", "
cfg/x32.scc", "" ,d)}"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image.bbclass: add function to disable SSH DNS Lookup for Qemu
This function disables the reverse DNS lookup on QEMU targets to reduce the
delay when using static IP address. By disabling DNS lookup we can save a great
deal of time during automated testing on the autobuilder (on the order of ~400
seconds per ssh tranaction). This is seen when using the testimage, there is a
delay getting logged-in from the server to target.
It's enabled for all qemu imgaes by default and can be overridden by setting
the SSH_DISABLE_DNS_LOOKUP variable.
[YOCTO #5954]
Signed-off-by: Saul Wold
---
meta/classes/image.bbclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 29309f5..ea035fe 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -304,6 +304,16 @@ ssh_allow_empty_password () {
fi
}
+# Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
+# distros to choose not to take this change
+SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
+ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
+ssh_disable_dns_lookup () {
+ if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
+ sed -i -e 's:#UseDNS yes:UseDNS no:'
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+ fi
+}
+
# Enable postinst logging if debug-tweaks is enabled
postinst_enable_logging () {
mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/default
--
1.8.3.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
On 31 March 2014 18:03, Richard Purdie wrote: > I kind of disagree with that, the LSB image can take into account > configuration in other parts of the system. If pam isn't configured, I'm > not sure that should automatically make it completely unbuildable... An image that claims to be LSB compliant but due to not-immediately-obvious DISTRO_FEATURES isn't actually doesn't seem like a good idea to me, fwiw. If the LSB image requires PAM, X11 and so on then it should require the features. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
On Monday 31 March 2014 18:03:32 Richard Purdie wrote: > On Mon, 2014-03-31 at 13:18 +0100, Paul Eggleton wrote: > > On Monday 31 March 2014 11:58:49 Stanacar, StefanX wrote: > > > On Mon, 2014-03-31 at 10:58 +0100, Richard Purdie wrote: > > > > On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: > > > > > core-image-lsb only gave a warning: > > > > > "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, > > > > > PAM won't work correctly" > > > > > when the proper DISTRO was not set for it. > > > > > default choice would be DISTRO = "poky-lsb", > > > > > but not necessarily, depending on each custom distro. > > > > > > > > > > This fix will enforce the proper usage of pam > > > > > as a distro feature for core-image-lsb by giving > > > > > an error instead of just a warning. > > > > > > > > > > Fixes [YOCTO #6073] > > > > > > > > > > Signed-off-by: Cristian Iorga > > > > > --- > > > > > > > > > > meta/recipes-extended/images/core-image-lsb.bb | 4 +++- > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/meta/recipes-extended/images/core-image-lsb.bb > > > > > b/meta/recipes-extended/images/core-image-lsb.bb index > > > > > ed316a6..ab61c6e > > > > > 100644 > > > > > --- a/meta/recipes-extended/images/core-image-lsb.bb > > > > > +++ b/meta/recipes-extended/images/core-image-lsb.bb > > > > > @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ > > > > > > > > > > packagegroup-core-lsb \ > > > > > " > > > > > > > > > > -inherit core-image > > > > > +inherit core-image distro_features_check > > > > > + > > > > > +REQUIRED_DISTRO_FEATURES = "pam" > > > > > > > > I have a feeling the autobuilder builds core-image-lsb in situations > > > > where DISTRO=poky, although I could be wrong. Have you checked? > > > > > > FWIW, all the -lsb buildsets are done with DISTRO=poky-lsb on the AB. > > > Unfortuntely we do have one problematic build. > > > So the answer to your question is: we don't have core-image-lsb builds > > > with DISTRO=poky but we do have a lib64-core-image-lsb-sdk image built > > > with DISTRO=poky and no pam in DISTRO_FEATURES, see the last build on > > > nightly-multilib... :( > > > > If we're doing this then we should be changing the autobuilder so it > > doesn't. LSB images should not be built in non-LSB configuration. > > I kind of disagree with that, the LSB image can take into account > configuration in other parts of the system. If pam isn't configured, I'm > not sure that should automatically make it completely unbuildable... For other situations I would agree, but the fact that the image has "lsb" in its name will naturally lead users to assume that that the output will be something LSB-compliant, but if poky-lsb or some other similar distro configuration is not used to build it then it will not be. Building something that's almost-LSB but not quite but is still labelled LSB just dilutes the meaning of LSB, and therefore doesn't seem to me to be particularly desirable. Since we can't just check if DISTRO is "poky-lsb", an alternative check would be to look for "linuxstdbase" in OVERRIDES since we ought to be able to rely upon that given usage within other recipes. 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
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
On Mon, 2014-03-31 at 13:18 +0100, Paul Eggleton wrote: > On Monday 31 March 2014 11:58:49 Stanacar, StefanX wrote: > > On Mon, 2014-03-31 at 10:58 +0100, Richard Purdie wrote: > > > On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: > > > > core-image-lsb only gave a warning: > > > > "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, > > > > PAM won't work correctly" > > > > when the proper DISTRO was not set for it. > > > > default choice would be DISTRO = "poky-lsb", > > > > but not necessarily, depending on each custom distro. > > > > > > > > This fix will enforce the proper usage of pam > > > > as a distro feature for core-image-lsb by giving > > > > an error instead of just a warning. > > > > > > > > Fixes [YOCTO #6073] > > > > > > > > Signed-off-by: Cristian Iorga > > > > --- > > > > > > > > meta/recipes-extended/images/core-image-lsb.bb | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/meta/recipes-extended/images/core-image-lsb.bb > > > > b/meta/recipes-extended/images/core-image-lsb.bb index ed316a6..ab61c6e > > > > 100644 > > > > --- a/meta/recipes-extended/images/core-image-lsb.bb > > > > +++ b/meta/recipes-extended/images/core-image-lsb.bb > > > > @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ > > > > > > > > packagegroup-core-lsb \ > > > > " > > > > > > > > -inherit core-image > > > > +inherit core-image distro_features_check > > > > + > > > > +REQUIRED_DISTRO_FEATURES = "pam" > > > > > > I have a feeling the autobuilder builds core-image-lsb in situations > > > where DISTRO=poky, although I could be wrong. Have you checked? > > > > FWIW, all the -lsb buildsets are done with DISTRO=poky-lsb on the AB. > > Unfortuntely we do have one problematic build. > > So the answer to your question is: we don't have core-image-lsb builds > > with DISTRO=poky but we do have a lib64-core-image-lsb-sdk image built > > with DISTRO=poky and no pam in DISTRO_FEATURES, see the last build on > > nightly-multilib... :( > > If we're doing this then we should be changing the autobuilder so it doesn't. > LSB images should not be built in non-LSB configuration. I kind of disagree with that, the LSB image can take into account configuration in other parts of the system. If pam isn't configured, I'm not sure that should automatically make it completely unbuildable... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] runqemu: Add option for custom BIOS directory
On Mon, 2014-03-31 at 09:48 -0700, Ricardo Neri wrote: > I just wanted to check if there are comments about this patch. It merged 10 days ago: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=68acafd7dc18f23707c95c90e871395ded81f84b Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] runqemu: Add option for custom BIOS directory
On Thu, 2014-03-20 at 12:35 -0700, Ricardo Neri wrote:
> Add support to specify a directory for custom BIOS, VGA BIOS and
> keymaps as supported by qemu (-L option). Even though this can be
> done through qemuparams, having this option provides better user
> experience by not having to specify a long and cluttered path along
> with other qemuparams that the user might want to specify.
>
> This new options assumes first that the path provided is relative to
> OECORE_NATIVE_SYSROOT and will check whether it exists before proceeding.
> If not, it will treat the provided path as absolute. This provides
> the user flexibility to use BIOS binaries generated inside or outside
> the OE build environment.
>
> Signed-off-by: Ricardo Neri
> ---
> scripts/runqemu | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index 619ffb6..b1d2d1a 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -149,6 +149,9 @@ while true; do
> SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT console=ttyS0"
> SERIALSTDIO="1"
> ;;
> + "biosdir="*)
> +CUSTOMBIOSDIR="${arg##biosdir=}"
> + ;;
> "qemuparams="*)
> SCRIPT_QEMU_EXTRA_OPT="${arg##qemuparams=}"
>
> @@ -489,5 +492,21 @@ if [ ! -f "$INTERNAL_SCRIPT" -o ! -r "$INTERNAL_SCRIPT"
> ]; then
> INTERNAL_SCRIPT=`which runqemu-internal`
> fi
>
> +# Specify directory for BIOS, VGA BIOS and keymaps
> +if [ ! -z "$CUSTOMBIOSDIR" ]; then
> +if [ -d "$OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" ]; then
> +echo "Assuming biosdir is $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR"
> +SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L
> $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR"
> +else
> +if [ ! -d "$CUSTOMBIOSDIR" ]; then
> +echo "Custom BIOS directory not found. Tried: $CUSTOMBIOSDIR"
> +echo "and $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR"
> +exit 1;
> +fi
> +echo "Assuming biosdir is $CUSTOMBIOSDIR"
> +SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $CUSTOMBIOSDIR"
> +fi
> +fi
> +
> . $INTERNAL_SCRIPT
> exit $?
Hi!
I just wanted to check if there are comments about this patch.
BR,
Ricardo
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] toaster.bbclass: the license.manifest is located in DEPLOY_DIR
From: Cristiana Voicu
Replaced DEPLOY_DIR_IMAGE with DEPLOY_DIR
[YOCTO #6051]
Signed-off-by: Cristiana Voicu
---
meta/classes/toaster.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/toaster.bbclass b/meta/classes/toaster.bbclass
index f55a4d7..9fb2cec 100644
--- a/meta/classes/toaster.bbclass
+++ b/meta/classes/toaster.bbclass
@@ -299,10 +299,10 @@ python toaster_buildhistory_dump() {
# dump information related to license manifest path
python toaster_licensemanifest_dump() {
-deploy_dir_image = d.getVar('DEPLOY_DIR_IMAGE', True);
+deploy_dir = d.getVar('DEPLOY_DIR', True);
image_name = d.getVar('IMAGE_NAME', True);
-data = { 'deploy_dir_image' : deploy_dir_image, 'image_name' : image_name }
+data = { 'deploy_dir' : deploy_dir, 'image_name' : image_name }
bb.event.fire(bb.event.MetadataEvent("LicenseManifestPath", data), d)
}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] toaster patchset pull request
From: Alexandru DAMIAN Hello, This is a Toaster pull request. The patches have been reviewed on the toaster mailinglist. Can you please pull ? Thanks, Alex The following changes since commit 8210928e847fda7dbc145a94372b0beaf653a4f9: yocto-bsps: remove linux-yocto 3.8 bbappend (2014-03-30 23:53:00 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib adamian/20140331-submission http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=adamian/20140331-submission Alexandru DAMIAN (1): sstate.bbclass: update missed sstate event Cristiana Voicu (1): toaster.bbclass: the license.manifest is located in DEPLOY_DIR meta/classes/sstate.bbclass | 12 ++-- meta/classes/toaster.bbclass | 4 ++-- 2 files changed, 12 insertions(+), 4 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] sstate.bbclass: update missed sstate event
From: Alexandru DAMIAN
This is a patch to update the missed sstate event with
info about the sstate files locations that were found.
It's needed as to display the found file in the toaster ui.
Also fixes a bug where a setscene task may have appeared in the
missed list even if it was found in a sstate mirror.
Signed-off-by: Alexandru DAMIAN
---
meta/classes/sstate.bbclass | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 25b8d72..f761909 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -690,6 +690,8 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d):
fetcher.checkstatus()
bb.debug(2, "SState: Successful fetch test for %s" % srcuri)
ret.append(task)
+if task in missed:
+missed.remove(task)
except:
missed.append(task)
bb.debug(2, "SState: Unsuccessful fetch test for %s" % srcuri)
@@ -697,9 +699,15 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d):
inheritlist = d.getVar("INHERIT", True)
if "toaster" in inheritlist:
-evdata = []
+evdata = {'missed': [], 'found': []};
for task in missed:
-evdata.append( (sq_fn[task], sq_task[task], sq_hash[task],
generate_sstatefn(spec, sq_hash[task],d) ) )
+spec, extrapath, tname = getpathcomponents(task, d)
+sstatefile = d.expand(extrapath + generate_sstatefn(spec,
sq_hash[task], d) + "_" + tname + ".tgz")
+evdata['missed'].append( (sq_fn[task], sq_task[task],
sq_hash[task], sstatefile ) )
+for task in ret:
+spec, extrapath, tname = getpathcomponents(task, d)
+sstatefile = d.expand(extrapath + generate_sstatefn(spec,
sq_hash[task], d) + "_" + tname + ".tgz")
+evdata['found'].append( (sq_fn[task], sq_task[task],
sq_hash[task], sstatefile ) )
bb.event.fire(bb.event.MetadataEvent("MissedSstate", evdata), d)
return ret
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Mon, 2014-03-31 at 17:10 +0200, Martin Jansa wrote:
> On Mon, Mar 31, 2014 at 10:20:49PM +0800, Kai Kang wrote:
> > From: Roy Li
> >
> > When native package is built, use the uname to return the kernel version.
> >
> > When target is built, read kernel version from
> > ${STAGING_KERNEL_DIR}/kernel-abiversion
> > to avoid to use the hardcode kernel version.
>
> Doesn't it make nss MACHINE_ARCH like most virtual/kernel providers are?
Agreed. I rejected this patch a while ago due to this and I'll reject it
again.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Mon, 2014-03-31 at 22:20 +0800, Kai Kang wrote: > I don't quite understand what you mean "this makes nss machine > specific". After update way for nss-native, I send this new version > for review. The kernel is machine specific. You're adding a dependency on the kernel to nss recipe. This means the nss recipe now depends on the kernel and the nss recipe is then also machine specific. We do not want nss to change each time you change machine. This was unacceptable last time you sent the patch, its still unacceptable. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] wic: Add --rootfs option to --source param
Hi, On Mon, Mar 31, 2014 at 11:39 AM, Tom Zanussi wrote: > > But I think you could accomplish the same thing by just allowing the > indirect string e.g. rootfs2 to resolve to either a full path, or as an > image name, which would be treated as an instance of '-e image-name' for > that partition. > > For example, we have the unmodified parttion in the .wks file as usual: > > part /standby --source rootfs --rootfs-dir=rootfs2 --ondisk sda > --fstype=ext3 --label secondary --align 1024 > > Which could be resolved as either a full path to the rootfs dir: > > wic create directdisk-multi-indirect-both --rootfs-dir > rootfs2=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal > > Or extracted from the '-e' ROOTFS_DIR output from the 'core-image-minimal' > image: > > wic create directdisk-multi-indirect-both --rootfs-dir > rootfs2=core-image-minimal > > Does that make sense for this? > > Yes. I think that is the point. -- João Henrique Ferreira de Freitas - joaohf_at_gmail.com Campinas-SP-Brasil -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On 30 March 2014 17:48, Khem Raj wrote: > On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: >> On 30 March 2014 05:17, Khem Raj wrote: >>> On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: On 26 March 2014 22:12, Burton, Ross wrote: > On 26 March 2014 22:04, Khem Raj wrote: >> There were interest in other threads in having musl as an alternative >> to eglibc/uclibc that we already have in OE, in that direction I have >> poured in my on and off work and put it into a contrib tree > > Blimey Khem that was quick. :) > Agreed! I wonder if it's worth splitting this out into its own layer though >>> >>> I thought about it and since class/conf changes that need to go in into >>> OE-core >>> first I kept it as it is (lazyness too). I think once the core support >>> is available in OE-core >>> we can spin the recipes into a layer of its own. >>> (with fixes done via bbappends) so that it's easy for multiple people to contribute to. It would also mean it doesn't need rebasing onto master all the time. I'd definitely like to get involved with this. In particular I can ensure opkg (both current release and development branch) work with musl and see if some of my preferred software from meta-oe will build (vim, htop, etc). >>> >>> start with what we have. Once master opens up I would propose the needed >>> changes to OE-core and spin a layer >>> >> >> I did a quick 'bitbake -k core-image-minimal' to see what's currently >> failing. Full logs and config at >> http://www.paulbarker.me.uk/musl-build/ >> >> Build Configuration: >> BB_VERSION= "1.21.1" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "Ubuntu-12.04" >> TARGET_SYS= "arm-oe-linux-musleabi" >> MACHINE = "qemuarm" >> DISTRO= "nodistro" >> DISTRO_VERSION= "nodistro.0" >> TUNE_FEATURES = "armv5 thumb dsp" >> TARGET_FPU= "soft" >> meta = "kraj/musl:faafa7022ed057d55c131c456d1bdd5dfa3d2517" >> >> Summary: 6 tasks failed: >> openembedded-core/meta/recipes-support/attr/attr_2.4.47.bb, do_compile >> openembedded-core/meta/recipes-devtools/python/python_2.7.3.bb, do_compile >> openembedded-core/meta/recipes-core/util-linux/util-linux_2.24.1.bb, >> do_compile >> openembedded-core/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb, >> do_compile >> openembedded-core/meta/recipes-core/busybox/busybox_1.22.1.bb, do_compile >> openembedded-core/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb, do_compile >> >> I can see for util-linux that we need to implement qsort_r(). >> >> Busybox probably just needs config changes: >> http://wiki.musl-libc.org/wiki/Building_Busybox > > > I already have local fix for busy box. Excellent! I'm currently looking at util-linux. I think we should ask for a new repo to be setup on git.yoctoproject.org for meta-musl. I'm happy to be one of the maintainers for that, I hope that you are as well and maybe a couple of the others who were interested could also help. I think having a few people as maintainers is important as we're all already fairly busy on other projects. Once the layer is setup we can move the recipes off your branch of oe-core and into the layer as time permits. That would just leave the changes which need to go into oe-core on your branch. Does that sound like a sensible plan? -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libomxil-0.9.3: fix configure unrecognised option
Drop --disable-ffmpegcomponents which is deprecated since
libomxil-bellagio-0.9.1
Explicitly disable doc generation to prevent using doxygen from build machine.
Components are external and are available separately here:
http://sourceforge.net/projects/omxil/files/components/
---
meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
index 4a7633d..103d789 100644
--- a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
+++ b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
@@ -1,11 +1,13 @@
-SUMMARY = "Bellagio OpenMAX Integration Layer"
+SUMMARY = "Bellagio OpenMAX Integration Layer (IL)"
+DESCRIPTION = "Bellagio is an opensource implementation of the Khronos OpenMAX
\
+ Integration Layer API to access multimedia components."
HOMEPAGE = "http://omxil.sourceforge.net/";
+
LICENSE = "LGPLv2.1+"
LICENSE_FLAGS = "commercial"
LIC_FILES_CHKSUM = "file://COPYING;md5=ae6f0f4dbc7ac193b50f323a6ae191cb \
file://src/omxcore.h;beginline=1;endline=27;md5=806b1e5566c06486fe8e42b461e03a90"
-
SRC_URI = "${SOURCEFORGE_MIRROR}/omxil/libomxil-bellagio-${PV}.tar.gz \
file://configure-fix.patch \
file://parallel-make.patch \
@@ -19,7 +21,7 @@ S = "${WORKDIR}/${BPN}-bellagio-${PV}"
inherit autotools
-EXTRA_OECONF += "--disable-ffmpegcomponents --disable-Werror"
+EXTRA_OECONF += "--disable-doc --disable-Werror"
FILES_${PN} += "${libdir}/bellagio/*${SOLIBS} \
${libdir}/omxloaders/*${SOLIBS}"
--
1.8.5.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo-1.5.1: keep install command directory mode
On Mon, Mar 31, 2014 at 10:37:36PM +0800, Kang Kai wrote:
> On 2014年03月31日 18:24, Martin Jansa wrote:
> > On Mon, Mar 31, 2014 at 04:35:30PM +0800, Kai Kang wrote:
> >> From: "yanjun.zhu"
> >>
> >> When install command sets the created directory mode, pseudo will change
> >> the mode of the directory to 0700 incorrectly. Backport patch to fix it.
> >>
> >> Drop PR as well.
> >>
> >> Signed-off-by: yanjun.zhu
> >> Signed-off-by: Kai Kang
> >> ---
> >> .../files/pseudo-1.5.1-install-directory-mode.patch| 18
> >> ++
> >> meta/recipes-devtools/pseudo/pseudo_1.5.1.bb | 3 +--
> >> 2 files changed, 19 insertions(+), 2 deletions(-)
> >> create mode 100644
> >> meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
> >>
> >> diff --git
> >> a/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
> >>
> >> b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
> >> new file mode 100644
> >> index 000..e8eaf13
> >> --- /dev/null
> >> +++
> >> b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
> >> @@ -0,0 +1,18 @@
> >> +Upstream-Status: Backport
> >> +
> >> +when install command sets the created directory mode, pseudo will change
> >> +the mode of the directory to 0700 incorrectly.
> >> +
> >> +Signed-off-by: yanjun.zhu
> >> +Signed-off-by: Kai Kang
> >> +
> >> +--- a/ports/unix/guts/mkdirat.c
> >> b/ports/unix/guts/mkdirat.c
> >> +@@ -25,6 +25,7 @@
> >> + stat_rc = base_fstatat(dirfd, path, &buf, AT_SYMLINK_NOFOLLOW);
> >> + #endif
> >> + if (stat_rc != -1) {
> >> ++ buf.st_mode = PSEUDO_DB_MODE(buf.st_mode, mode);
> >> + pseudo_client_op(OP_MKDIR, 0, -1, dirfd, path, &buf);
> >> + } else {
> >> + pseudo_debug(1, "mkdir of %s succeeded, but stat
> >> failed: %s\n",
> >> diff --git a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> >> b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> >> index bc92856..c265017 100644
> >> --- a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> >> +++ b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> >> @@ -1,11 +1,10 @@
> >> require pseudo.inc
> >>
> >> -PR = "r4"
> > You cannot drop PR when PV/PE is the same, version goes backward (you
> > should notice QA Error about that).
>
> Sorry, forget that. But I didn't meet the QA Error. When should it
> appear, parse recipes or do_package_qa?
do_package_qa (iirc it needs buildhistory enabled in order to detect it
between "clean" builds).
> I'll send V2.
>
> Thanks,
> Kai
>
> >
> >> -
> >> SRC_URI = " \
> >> http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2 \
> >> file://0001-pseudo_has_unload-add-function.patch \
> >> file://shutdownping.patch \
> >> +file://pseudo-1.5.1-install-directory-mode.patch \
> >> "
> >>
> >> SRC_URI[md5sum] = "5ec67c7bff5fe68c56de500859c19172"
> >> --
> >> 1.8.4
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
> --
> Regards,
> Neil | Kai Kang
>
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Mon, Mar 31, 2014 at 10:20:49PM +0800, Kai Kang wrote:
> From: Roy Li
>
> When native package is built, use the uname to return the kernel version.
>
> When target is built, read kernel version from
> ${STAGING_KERNEL_DIR}/kernel-abiversion
> to avoid to use the hardcode kernel version.
Doesn't it make nss MACHINE_ARCH like most virtual/kernel providers are?
> Signed-off-by: Roy Li
> Signed-off-by: Kai Kang
> ---
> meta/recipes-support/nss/nss.inc | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-support/nss/nss.inc
> b/meta/recipes-support/nss/nss.inc
> index 404decc..f24da68 100644
> --- a/meta/recipes-support/nss/nss.inc
> +++ b/meta/recipes-support/nss/nss.inc
> @@ -26,6 +26,7 @@ SRC_URI_append_class-target = "\
> inherit siteinfo
> PR = "r0"
> DEPENDS = "sqlite3 nspr zlib nss-native"
> +DEPENDS_append_class-target += "virtual/kernel"
> DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
> RDEPENDS_${PN} = "perl"
>
> @@ -37,12 +38,24 @@ TARGET_CC_ARCH += "${LDFLAGS}"
> do_compile_prepend_class-native() {
> export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
> export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
> +export OS_RELEASE=`uname -r`
> }
>
> do_compile_prepend_class-nativesdk() {
> export LDFLAGS=""
> }
>
> +do_compile_prepend_class-target() {
> +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
> 's/-.*//'`
> +}
> +
> +do_install_prepend_class-native() {
> +export OS_RELEASE=`uname -r`
> +}
> +
> +do_install_prepend_class-target() {
> +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
> 's/-.*//'`
> +}
> do_compile() {
> export CROSS_COMPILE=1
> export NATIVE_CC="gcc"
> @@ -57,7 +70,6 @@ do_compile() {
> export NSS_USE_SYSTEM_SQLITE=1
> export NSS_ENABLE_ECC=1
>
> -export OS_RELEASE=3.4
> export OS_TARGET=Linux
> export OS_ARCH=Linux
>
> @@ -97,7 +109,6 @@ do_install() {
> export NSS_USE_SYSTEM_SQLITE=1
> export NSS_ENABLE_ECC=1
>
> -export OS_RELEASE=3.4
> export OS_TARGET=Linux
> export OS_ARCH=Linux
>
> --
> 1.8.1.2
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image.bbclass: add postprocess func to disable DNS lookups for openssh
In the default config openssh does reverse DNS resolution, but
if there is no DNS configured on the target (or even worse the
DNS server is unreachable) there is a long timeout when connecting
over ssh. This is most visible on core-image-sato-sdk builds on AB, where the
tests take a long time because each ssh command spends 15 seconds
just connecting to the target, disabling the reverse DNS resolution halves
the total test time.
This isn't a qemu specific problem however and instead of changing the default
config I think it's worth disabling this when debug-tweaks is enabled.
Patch based on a previous version sent by Saul Wold
[YOCTO #5954]
Signed-off-by: Stefan Stanacar
---
meta/classes/image.bbclass | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 29309f5..846c768 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -146,6 +146,8 @@ MACHINE_POSTPROCESS_COMMAND ?= ""
ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES",
"debug-tweaks", "ssh_allow_empty_password; ", "",d)}'
# Enable postinst logging if debug-tweaks is enabled
ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES",
"debug-tweaks", "postinst_enable_logging; ", "",d)}'
+# Disable DNS lookups if debug-tweaks is enabled
+ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES",
"debug-tweaks", "ssh_disable_dns_lookup; ", "",d)}'
# Write manifest
IMAGE_MANIFEST = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest"
ROOTFS_POSTPROCESS_COMMAND =+ "write_image_manifest ; "
@@ -304,6 +306,12 @@ ssh_allow_empty_password () {
fi
}
+ssh_disable_dns_lookup () {
+if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
+sed -i -e 's:#UseDNS yes:UseDNS no:'
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+fi
+}
+
# Enable postinst logging if debug-tweaks is enabled
postinst_enable_logging () {
mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/default
@@ -374,7 +382,7 @@ rootfs_sysroot_relativelinks () {
sysroot-relativelinks.py ${SDK_OUTPUT}/${SDKTARGETSYSROOT}
}
-EXPORT_FUNCTIONS zap_empty_root_password remove_init_link do_rootfs
make_zimage_symlink_relative set_image_autologin rootfs_update_timestamp
rootfs_no_x_startup
+EXPORT_FUNCTIONS zap_empty_root_password remove_init_link do_rootfs
make_zimage_symlink_relative set_image_autologin rootfs_update_timestamp
rootfs_no_x_startup ssh_disable_dns_lookup
do_fetch[noexec] = "1"
do_unpack[noexec] = "1"
--
1.9.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libomxil-0.9.3: fix configure unrecognised option
On 31 March 2014 16:39, Matthieu Crapet wrote: > -EXTRA_OECONF += "--disable-ffmpegcomponents --disable-Werror" > +EXTRA_OECONF += "--disable-doc --disable-Werror" --disable-doc is new but wasn't mentioned in the commit message, please explain why it was added. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libomxil-0.9.3: fix configure unrecognised option
Drop --disable-ffmpegcomponents which is deprecated since
libomxil-bellagio-0.9.1
Components are external and are available separately here:
http://sourceforge.net/projects/omxil/files/components/
---
meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
index 4a7633d..103d789 100644
--- a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
+++ b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
@@ -1,11 +1,13 @@
-SUMMARY = "Bellagio OpenMAX Integration Layer"
+SUMMARY = "Bellagio OpenMAX Integration Layer (IL)"
+DESCRIPTION = "Bellagio is an opensource implementation of the Khronos OpenMAX
\
+ Integration Layer API to access multimedia components."
HOMEPAGE = "http://omxil.sourceforge.net/";
+
LICENSE = "LGPLv2.1+"
LICENSE_FLAGS = "commercial"
LIC_FILES_CHKSUM = "file://COPYING;md5=ae6f0f4dbc7ac193b50f323a6ae191cb \
file://src/omxcore.h;beginline=1;endline=27;md5=806b1e5566c06486fe8e42b461e03a90"
-
SRC_URI = "${SOURCEFORGE_MIRROR}/omxil/libomxil-bellagio-${PV}.tar.gz \
file://configure-fix.patch \
file://parallel-make.patch \
@@ -19,7 +21,7 @@ S = "${WORKDIR}/${BPN}-bellagio-${PV}"
inherit autotools
-EXTRA_OECONF += "--disable-ffmpegcomponents --disable-Werror"
+EXTRA_OECONF += "--disable-doc --disable-Werror"
FILES_${PN} += "${libdir}/bellagio/*${SOLIBS} \
${libdir}/omxloaders/*${SOLIBS}"
--
1.8.5.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] pseudo-1.5.1: keep install command directory mode
From: "yanjun.zhu"
When install command sets the created directory mode, pseudo will change
the mode of the directory to 0700 incorrectly. Backport patch to fix it.
Signed-off-by: yanjun.zhu
Signed-off-by: Kai Kang
---
.../files/pseudo-1.5.1-install-directory-mode.patch| 18 ++
meta/recipes-devtools/pseudo/pseudo_1.5.1.bb | 1 +
2 files changed, 19 insertions(+)
create mode 100644
meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
diff --git
a/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
new file mode 100644
index 000..e8eaf13
--- /dev/null
+++
b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
@@ -0,0 +1,18 @@
+Upstream-Status: Backport
+
+when install command sets the created directory mode, pseudo will change
+the mode of the directory to 0700 incorrectly.
+
+Signed-off-by: yanjun.zhu
+Signed-off-by: Kai Kang
+
+--- a/ports/unix/guts/mkdirat.c
b/ports/unix/guts/mkdirat.c
+@@ -25,6 +25,7 @@
+ stat_rc = base_fstatat(dirfd, path, &buf, AT_SYMLINK_NOFOLLOW);
+ #endif
+ if (stat_rc != -1) {
++ buf.st_mode = PSEUDO_DB_MODE(buf.st_mode, mode);
+ pseudo_client_op(OP_MKDIR, 0, -1, dirfd, path, &buf);
+ } else {
+ pseudo_debug(1, "mkdir of %s succeeded, but stat
failed: %s\n",
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
index bc92856..215cdb8 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
@@ -6,6 +6,7 @@ SRC_URI = " \
http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0001-pseudo_has_unload-add-function.patch \
file://shutdownping.patch \
+file://pseudo-1.5.1-install-directory-mode.patch \
"
SRC_URI[md5sum] = "5ec67c7bff5fe68c56de500859c19172"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] V2: pseudo-1.5.1: keep install command directory mode
V2: * keep PR yanjun.zhu (1): pseudo-1.5.1: keep install command directory mode .../files/pseudo-1.5.1-install-directory-mode.patch| 18 ++ meta/recipes-devtools/pseudo/pseudo_1.5.1.bb | 1 + 2 files changed, 19 insertions(+) create mode 100644 meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] wic: Add --rootfs option to --source param
On Sun, 2014-03-30 at 22:52 -0300, João Henrique Ferreira de Freitas wrote: > Hi Tom, > > Let's back in this context. This is really important and I was waiting > to complete the previous stage. > > Em 17-03-2014 13:11, Otavio Salvador escreveu: > >>> > >>> If my understand is right, I like the feature. My only concern is > >>> people overusing it and adding contents which are not 'tracked' in the > >>> build system in a product release which seems attractive when we first > >>> think about it but cause some management, tracking and authenticity > >>> check problems in long term. > >>> > >>> > >>> I don't know how to better address this from wic perspective. Usually > >>> we end doing multiple images as part of the build process for those > >>> special cases and I don't know how wic could be 'told' about those > >>> secondary rootfs existence. > >>> > > I have been working on it since Otavio's concerns about 'contents which > are not tracked'. > > So extending my previous patches (80% done) to handle this situation is > quite easy. Like this: > > bitbake directdisk-multi-image-e img1=core-image-minimal -e > img2=core-image-minimal -e img3=core-image-minimal > > directdisk-multi-image.wks: > > part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos --label > boot --active --align 1024 > > part / --source rootfs --image-name=img1 --ondisk sda --fstype=ext3 > --label primary --align 1024 > > part /standby --source rootfs --image-name=img2 --ondisk sda > --fstype=ext3 --label secondary --align 1024 > > part /root --source rootfs --image-name=img3 --ondisk sda --fstype=ext3 > --label root_sec --align 1024 > > > If the user put '--image-name' and '--rootfs-dir' the '--image-name' > takes precedence. > > As wic is a generic tool, the user could prefer to use images from OE or > any other rootfs-dir. > > Tom, what do you think? Could I go ahead? > So is the idea that you want to allow the user the convenience of being able to use the equivalent of '-e imagename' for any partition, rather than having to explicitly specify the full path? '-e imagename' was always meant as just a convenience to the user, since currently the easiest way to generate the artifacts is to first create an oe image. If you think about it, having to create an oe image or images in order to create another (wic-generated) image doesn't really make a lot of sense - it's basically just a temporary situation pending better integration, etc. So for that reason, I wouldn't want to see the idea of an --image-name incorporated into the image-creation .wks files. But I think you could accomplish the same thing by just allowing the indirect string e.g. rootfs2 to resolve to either a full path, or as an image name, which would be treated as an instance of '-e image-name' for that partition. For example, we have the unmodified parttion in the .wks file as usual: part /standby --source rootfs --rootfs-dir=rootfs2 --ondisk sda --fstype=ext3 --label secondary --align 1024 Which could be resolved as either a full path to the rootfs dir: wic create directdisk-multi-indirect-both --rootfs-dir rootfs2=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal Or extracted from the '-e' ROOTFS_DIR output from the 'core-image-minimal' image: wic create directdisk-multi-indirect-both --rootfs-dir rootfs2=core-image-minimal Does that make sense for this? Tom > Thanks > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo-1.5.1: keep install command directory mode
On 2014年03月31日 18:24, Martin Jansa wrote:
On Mon, Mar 31, 2014 at 04:35:30PM +0800, Kai Kang wrote:
From: "yanjun.zhu"
When install command sets the created directory mode, pseudo will change
the mode of the directory to 0700 incorrectly. Backport patch to fix it.
Drop PR as well.
Signed-off-by: yanjun.zhu
Signed-off-by: Kai Kang
---
.../files/pseudo-1.5.1-install-directory-mode.patch| 18 ++
meta/recipes-devtools/pseudo/pseudo_1.5.1.bb | 3 +--
2 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
diff --git
a/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
new file mode 100644
index 000..e8eaf13
--- /dev/null
+++
b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
@@ -0,0 +1,18 @@
+Upstream-Status: Backport
+
+when install command sets the created directory mode, pseudo will change
+the mode of the directory to 0700 incorrectly.
+
+Signed-off-by: yanjun.zhu
+Signed-off-by: Kai Kang
+
+--- a/ports/unix/guts/mkdirat.c
b/ports/unix/guts/mkdirat.c
+@@ -25,6 +25,7 @@
+ stat_rc = base_fstatat(dirfd, path, &buf, AT_SYMLINK_NOFOLLOW);
+ #endif
+ if (stat_rc != -1) {
++ buf.st_mode = PSEUDO_DB_MODE(buf.st_mode, mode);
+ pseudo_client_op(OP_MKDIR, 0, -1, dirfd, path, &buf);
+ } else {
+ pseudo_debug(1, "mkdir of %s succeeded, but stat failed:
%s\n",
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
index bc92856..c265017 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
@@ -1,11 +1,10 @@
require pseudo.inc
-PR = "r4"
You cannot drop PR when PV/PE is the same, version goes backward (you
should notice QA Error about that).
Sorry, forget that. But I didn't meet the QA Error. When should it
appear, parse recipes or do_package_qa?
I'll send V2.
Thanks,
Kai
-
SRC_URI = " \
http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0001-pseudo_has_unload-add-function.patch \
file://shutdownping.patch \
+file://pseudo-1.5.1-install-directory-mode.patch \
"
SRC_URI[md5sum] = "5ec67c7bff5fe68c56de500859c19172"
--
1.8.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Regards,
Neil | Kai Kang
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Mon, Mar 31, 2014 at 11:20 AM, Kai Kang wrote:
> From: Roy Li
>
> When native package is built, use the uname to return the kernel version.
>
> When target is built, read kernel version from
> ${STAGING_KERNEL_DIR}/kernel-abiversion
> to avoid to use the hardcode kernel version.
>
> Signed-off-by: Roy Li
> Signed-off-by: Kai Kang
This makes it depends on virtual/kernel and it vary from one machine to another.
Am I missing anything here?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] nss: avoid to use the hardcode kernel version
From: Roy Li
When native package is built, use the uname to return the kernel version.
When target is built, read kernel version from
${STAGING_KERNEL_DIR}/kernel-abiversion
to avoid to use the hardcode kernel version.
Signed-off-by: Roy Li
Signed-off-by: Kai Kang
---
meta/recipes-support/nss/nss.inc | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/nss/nss.inc b/meta/recipes-support/nss/nss.inc
index 404decc..f24da68 100644
--- a/meta/recipes-support/nss/nss.inc
+++ b/meta/recipes-support/nss/nss.inc
@@ -26,6 +26,7 @@ SRC_URI_append_class-target = "\
inherit siteinfo
PR = "r0"
DEPENDS = "sqlite3 nspr zlib nss-native"
+DEPENDS_append_class-target += "virtual/kernel"
DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
RDEPENDS_${PN} = "perl"
@@ -37,12 +38,24 @@ TARGET_CC_ARCH += "${LDFLAGS}"
do_compile_prepend_class-native() {
export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
+export OS_RELEASE=`uname -r`
}
do_compile_prepend_class-nativesdk() {
export LDFLAGS=""
}
+do_compile_prepend_class-target() {
+export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
's/-.*//'`
+}
+
+do_install_prepend_class-native() {
+export OS_RELEASE=`uname -r`
+}
+
+do_install_prepend_class-target() {
+export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
's/-.*//'`
+}
do_compile() {
export CROSS_COMPILE=1
export NATIVE_CC="gcc"
@@ -57,7 +70,6 @@ do_compile() {
export NSS_USE_SYSTEM_SQLITE=1
export NSS_ENABLE_ECC=1
-export OS_RELEASE=3.4
export OS_TARGET=Linux
export OS_ARCH=Linux
@@ -97,7 +109,6 @@ do_install() {
export NSS_USE_SYSTEM_SQLITE=1
export NSS_ENABLE_ECC=1
-export OS_RELEASE=3.4
export OS_TARGET=Linux
export OS_ARCH=Linux
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] nss: avoid to use the hardcode kernel version
Hi Richard, I don't quite understand what you mean "this makes nss machine specific". After update way for nss-native, I send this new version for review. Thanks. Roy Li (1): nss: avoid to use the hardcode kernel version meta/recipes-support/nss/nss.inc | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] gtk+3: set proper FLAGS for native
On 30 March 2014 11:30, Robert Yang wrote: >++CFLAGS = @CFLAGS_FOR_BUILD@ >++CPPFLAGS = @CPPFLAGS_FOR_BUILD@ >++LDFLAGS = @LDFLAGS_FOR_BUILD@ So the problem is that the environment is providing a CFLAGS variable that automake is then using for native builds alongside CFLAGS_FOR_BUILD. Instead of replicating the variables, which this will do, would it be better to unset CFLAGS/CPPFLAGS/LDFLAGS in this makefile so the environment variables are not used? (as makefile assignments override environment assignments). Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] packagegroup-core-tools-testapps: Move GLTOOLS to X11GLTOOLS
piglit and mesa-demos are not buildable in x11-less distros so we must
to add those only when opengl and x11 DISTRO_FEATURES are available.
Signed-off-by: Otavio Salvador
---
meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
index d8a7306..952fbd0 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
@@ -24,7 +24,7 @@ KEXECTOOLS_powerpc ?= ""
KEXECTOOLS_e5500-64b ?= ""
KEXECTOOLS_aarch64 ?= ""
-GLTOOLS = "\
+X11GLTOOLS = "\
mesa-demos \
piglit \
"
@@ -58,6 +58,6 @@ RDEPENDS_${PN} = "\
connman-tests \
connman-client \
${@base_contains('DISTRO_FEATURES', 'x11', "${X11TOOLS}", "", d)} \
-${@base_contains('DISTRO_FEATURES', 'opengl', "${GLTOOLS}", "", d)} \
+${@base_contains('DISTRO_FEATURES', 'x11 opengl', "${X11GLTOOLS}", "", d)}
\
${@base_contains('DISTRO_FEATURES', '3g', "${3GTOOLS}", "", d)} \
"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] packagegroup-core-tools-testapps: Move GLTOOLS to X11GLTOOLS
On 31 March 2014 14:47, Otavio Salvador wrote: >> I'm surprised that piglit needs libx11, waffle should be abstracting >> that. I'll have a quick look. > > Could we merge this and then fix piglit? I will send v2 as suggested > by Richard, so we can address this. Sure, this might need a piglit upgrade so would be 1.7 material anyway. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] packagegroup-core-tools-testapps: Move GLTOOLS to X11GLTOOLS
On Mon, Mar 31, 2014 at 7:14 AM, Burton, Ross wrote: > On 29 March 2014 20:04, Otavio Salvador wrote: >> piglit and mesa-demos are not buildable in x11-less distros so we must >> to add those only when opengl and x11 DISTRO_FEATURES are available. > > I'm surprised that piglit needs libx11, waffle should be abstracting > that. I'll have a quick look. Could we merge this and then fix piglit? I will send v2 as suggested by Richard, so we can address this. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc: changed multilib options handling
Duplicate parameters in the tune args are repeated in the
MULTILIB_OPTIONS variable. This leads to incorrect configurations
if the order of the parameters is bad.
(Eg. "mhard-float m32/mhard-float m64" leads to an incorrect config)
This patch finds the common parameters and removes the duplicates.
Signed-off-by: Alexandru-Cezar Sardan
---
meta/recipes-devtools/gcc/gcc-multilib-config.inc | 24 +
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
index 005aa6b..30745a6 100644
--- a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
+++ b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
@@ -148,6 +148,7 @@ python gcc_multilib_setup() {
options = []
dirnames = []
osdirnames = []
+optsets = []
for ml in ml_list:
tune = d.getVar(ml, True)
@@ -172,16 +173,31 @@ python gcc_multilib_setup() {
else:
bb.error('Unknown libdir (%s) of the tune : %s' % (tune_baselib,
tune))
-# take out '-' and march='s from parameters
-options.append(re.sub(r'march=[^ ]+ *', '',
-re.sub(r' +\-+', ' ',
-re.sub(r'^ *\-+', '',
tune_parameters['ccargs']
+# take out '-' mcpu='s and march='s from parameters
+options.append(re.sub(r'mcpu=[^ ]+ *', '',
+ re.sub(r'march=[^ ]+ *', '',
+ re.sub(r' +\-+', ' ',
+ re.sub(r'^ *\-+', '',
tune_parameters['ccargs'])
if tune_baselib == 'lib':
dirnames.append('32') # /lib => 32bit lib
else:
dirnames.append(tune_baselib.replace('lib', ''))
osdirnames.append('../' + tune_baselib)
+if len(options) > 1:
+for optstr in options:
+optsets.append(optstr.split())
+
+#get common options present in all the tune parameters
+common_opt_set = set.intersection(*map(set, optsets))
+
+#common options will be added at the end of the options string only once
+if (len(common_opt_set) > 0):
+rex = re.compile(''.join(['\\b(', '|'.join(common_opt_set),
')\\W']), re.I)
+options = [rex.sub("", optstr) for optstr in options]
+options = [optstr.strip() for optstr in options]
+options[len(options)-1] = ' '.join((options[len(options)-1], '
'.join(common_opt_set)))
+
write_config(builddir, target_config_files, options, dirnames, osdirnames)
write_headers(builddir, header_config_files, libdir32, libdir64,
libdirx32, libdirn32)
}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
On Monday 31 March 2014 11:58:49 Stanacar, StefanX wrote: > On Mon, 2014-03-31 at 10:58 +0100, Richard Purdie wrote: > > On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: > > > core-image-lsb only gave a warning: > > > "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, > > > PAM won't work correctly" > > > when the proper DISTRO was not set for it. > > > default choice would be DISTRO = "poky-lsb", > > > but not necessarily, depending on each custom distro. > > > > > > This fix will enforce the proper usage of pam > > > as a distro feature for core-image-lsb by giving > > > an error instead of just a warning. > > > > > > Fixes [YOCTO #6073] > > > > > > Signed-off-by: Cristian Iorga > > > --- > > > > > > meta/recipes-extended/images/core-image-lsb.bb | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/meta/recipes-extended/images/core-image-lsb.bb > > > b/meta/recipes-extended/images/core-image-lsb.bb index ed316a6..ab61c6e > > > 100644 > > > --- a/meta/recipes-extended/images/core-image-lsb.bb > > > +++ b/meta/recipes-extended/images/core-image-lsb.bb > > > @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ > > > > > > packagegroup-core-lsb \ > > > " > > > > > > -inherit core-image > > > +inherit core-image distro_features_check > > > + > > > +REQUIRED_DISTRO_FEATURES = "pam" > > > > I have a feeling the autobuilder builds core-image-lsb in situations > > where DISTRO=poky, although I could be wrong. Have you checked? > > FWIW, all the -lsb buildsets are done with DISTRO=poky-lsb on the AB. > Unfortuntely we do have one problematic build. > So the answer to your question is: we don't have core-image-lsb builds > with DISTRO=poky but we do have a lib64-core-image-lsb-sdk image built > with DISTRO=poky and no pam in DISTRO_FEATURES, see the last build on > nightly-multilib... :( If we're doing this then we should be changing the autobuilder so it doesn't. LSB images should not be built in non-LSB configuration. 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
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
On Mon, 2014-03-31 at 10:58 +0100, Richard Purdie wrote: > On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: > > core-image-lsb only gave a warning: > > "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, > > PAM won't work correctly" > > when the proper DISTRO was not set for it. > > default choice would be DISTRO = "poky-lsb", > > but not necessarily, depending on each custom distro. > > > > This fix will enforce the proper usage of pam > > as a distro feature for core-image-lsb by giving > > an error instead of just a warning. > > > > Fixes [YOCTO #6073] > > > > Signed-off-by: Cristian Iorga > > --- > > meta/recipes-extended/images/core-image-lsb.bb | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/meta/recipes-extended/images/core-image-lsb.bb > > b/meta/recipes-extended/images/core-image-lsb.bb > > index ed316a6..ab61c6e 100644 > > --- a/meta/recipes-extended/images/core-image-lsb.bb > > +++ b/meta/recipes-extended/images/core-image-lsb.bb > > @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ > > packagegroup-core-lsb \ > > " > > > > -inherit core-image > > +inherit core-image distro_features_check > > + > > +REQUIRED_DISTRO_FEATURES = "pam" > > > I have a feeling the autobuilder builds core-image-lsb in situations > where DISTRO=poky, although I could be wrong. Have you checked? > FWIW, all the -lsb buildsets are done with DISTRO=poky-lsb on the AB. Unfortuntely we do have one problematic build. So the answer to your question is: we don't have core-image-lsb builds with DISTRO=poky but we do have a lib64-core-image-lsb-sdk image built with DISTRO=poky and no pam in DISTRO_FEATURES, see the last build on nightly-multilib... :( Cheers, Stefan > 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] core-image-lsb: enforce pam as a needed distro feature
Hello, I have checked, on the autobuilder the right association between LSB-enabled images and proper distro (in our case, poky-lsb) is in place. As such, my patch should not cause any trouble. Regards, Cristian -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Iorga, Cristian Sent: Monday, March 31, 2014 1:10 PM To: Richard Purdie Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature No, but I will. But is this a negative point of the patch, or the autobuilder should be changed? I acted upon some personal observations, a discussion with Paul (he suggested the change) and also on this guide: https://wiki.yoctoproject.org/wiki/LSB_Result (in which distro is set to poky-lsb). Regards, Cristian -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Monday, March 31, 2014 12:58 PM To: Iorga, Cristian Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: > core-image-lsb only gave a warning: > "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM > won't work correctly" > when the proper DISTRO was not set for it. > default choice would be DISTRO = "poky-lsb", but not necessarily, > depending on each custom distro. > > This fix will enforce the proper usage of pam as a distro feature for > core-image-lsb by giving an error instead of just a warning. > > Fixes [YOCTO #6073] > > Signed-off-by: Cristian Iorga > --- > meta/recipes-extended/images/core-image-lsb.bb | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-extended/images/core-image-lsb.bb > b/meta/recipes-extended/images/core-image-lsb.bb > index ed316a6..ab61c6e 100644 > --- a/meta/recipes-extended/images/core-image-lsb.bb > +++ b/meta/recipes-extended/images/core-image-lsb.bb > @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ > packagegroup-core-lsb \ > " > > -inherit core-image > +inherit core-image distro_features_check > + > +REQUIRED_DISTRO_FEATURES = "pam" I have a feeling the autobuilder builds core-image-lsb in situations where DISTRO=poky, although I could be wrong. Have you checked? Cheers, Richard -- ___ 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 1/1] classes/sanity: check if SDKMACHINE setting has taken effect
If you try to set SDKMACHINE in a distro configuration file, it won't
take effect because by the time that is parsed the line in bitbake.conf
which includes the appropriate conf file for SDKMACHINE has already been
parsed. Check that SDK_ARCH has changed from its default value and show
an error if it hasn't in order to catch this misconfiguration.
Fixes [YOCTO #5861].
Signed-off-by: Paul Eggleton
---
meta/classes/sanity.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index cf514d0..69d6a24 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -667,6 +667,8 @@ def check_sanity_everybuild(status, d):
if d.getVar('SDKMACHINE', True):
if not check_conf_exists("conf/machine-sdk/${SDKMACHINE}.conf", d):
status.addresult('Specified SDKMACHINE value is not valid\n')
+elif d.getVar('SDK_ARCH', False) == "${BUILD_ARCH}":
+status.addresult('SDKMACHINE is set, but SDK_ARCH has not been
changed as a result - SDKMACHINE may have been set too late (e.g. in the distro
configuration)\n')
check_supported_distro(d)
--
1.9.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Check if SDKMACHINE setting has taken effect
The following change since commit 2116e326d9d7039aac4ec6c7ae5d2a2bedfb4a74: linux-yocto/3.10: fix qemuarm build failure (2014-03-30 23:52:10 +0100) is available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/sdkmachine http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/sdkmachine Paul Eggleton (1): classes/sanity: check if SDKMACHINE setting has taken effect meta/classes/sanity.bbclass | 2 ++ 1 file changed, 2 insertions(+) -- 1.9.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo-1.5.1: keep install command directory mode
On Mon, Mar 31, 2014 at 04:35:30PM +0800, Kai Kang wrote:
> From: "yanjun.zhu"
>
> When install command sets the created directory mode, pseudo will change
> the mode of the directory to 0700 incorrectly. Backport patch to fix it.
>
> Drop PR as well.
>
> Signed-off-by: yanjun.zhu
> Signed-off-by: Kai Kang
> ---
> .../files/pseudo-1.5.1-install-directory-mode.patch| 18
> ++
> meta/recipes-devtools/pseudo/pseudo_1.5.1.bb | 3 +--
> 2 files changed, 19 insertions(+), 2 deletions(-)
> create mode 100644
> meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
>
> diff --git
> a/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
>
> b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
> new file mode 100644
> index 000..e8eaf13
> --- /dev/null
> +++
> b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
> @@ -0,0 +1,18 @@
> +Upstream-Status: Backport
> +
> +when install command sets the created directory mode, pseudo will change
> +the mode of the directory to 0700 incorrectly.
> +
> +Signed-off-by: yanjun.zhu
> +Signed-off-by: Kai Kang
> +
> +--- a/ports/unix/guts/mkdirat.c
> b/ports/unix/guts/mkdirat.c
> +@@ -25,6 +25,7 @@
> + stat_rc = base_fstatat(dirfd, path, &buf, AT_SYMLINK_NOFOLLOW);
> + #endif
> + if (stat_rc != -1) {
> ++buf.st_mode = PSEUDO_DB_MODE(buf.st_mode, mode);
> + pseudo_client_op(OP_MKDIR, 0, -1, dirfd, path, &buf);
> + } else {
> + pseudo_debug(1, "mkdir of %s succeeded, but stat
> failed: %s\n",
> diff --git a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> index bc92856..c265017 100644
> --- a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> +++ b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
> @@ -1,11 +1,10 @@
> require pseudo.inc
>
> -PR = "r4"
You cannot drop PR when PV/PE is the same, version goes backward (you
should notice QA Error about that).
> -
> SRC_URI = " \
> http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2 \
> file://0001-pseudo_has_unload-add-function.patch \
> file://shutdownping.patch \
> +file://pseudo-1.5.1-install-directory-mode.patch \
> "
>
> SRC_URI[md5sum] = "5ec67c7bff5fe68c56de500859c19172"
> --
> 1.8.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] packagegroup-core-tools-testapps: Move GLTOOLS to X11GLTOOLS
On 29 March 2014 20:04, Otavio Salvador wrote: > piglit and mesa-demos are not buildable in x11-less distros so we must > to add those only when opengl and x11 DISTRO_FEATURES are available. I'm surprised that piglit needs libx11, waffle should be abstracting that. I'll have a quick look. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
No, but I will. But is this a negative point of the patch, or the autobuilder should be changed? I acted upon some personal observations, a discussion with Paul (he suggested the change) and also on this guide: https://wiki.yoctoproject.org/wiki/LSB_Result (in which distro is set to poky-lsb). Regards, Cristian -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Monday, March 31, 2014 12:58 PM To: Iorga, Cristian Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: > core-image-lsb only gave a warning: > "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM > won't work correctly" > when the proper DISTRO was not set for it. > default choice would be DISTRO = "poky-lsb", but not necessarily, > depending on each custom distro. > > This fix will enforce the proper usage of pam as a distro feature for > core-image-lsb by giving an error instead of just a warning. > > Fixes [YOCTO #6073] > > Signed-off-by: Cristian Iorga > --- > meta/recipes-extended/images/core-image-lsb.bb | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-extended/images/core-image-lsb.bb > b/meta/recipes-extended/images/core-image-lsb.bb > index ed316a6..ab61c6e 100644 > --- a/meta/recipes-extended/images/core-image-lsb.bb > +++ b/meta/recipes-extended/images/core-image-lsb.bb > @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ > packagegroup-core-lsb \ > " > > -inherit core-image > +inherit core-image distro_features_check > + > +REQUIRED_DISTRO_FEATURES = "pam" I have a feeling the autobuilder builds core-image-lsb in situations where DISTRO=poky, although I could be wrong. Have you checked? 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] core-image-lsb: enforce pam as a needed distro feature
On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: > core-image-lsb only gave a warning: > "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, > PAM won't work correctly" > when the proper DISTRO was not set for it. > default choice would be DISTRO = "poky-lsb", > but not necessarily, depending on each custom distro. > > This fix will enforce the proper usage of pam > as a distro feature for core-image-lsb by giving > an error instead of just a warning. > > Fixes [YOCTO #6073] > > Signed-off-by: Cristian Iorga > --- > meta/recipes-extended/images/core-image-lsb.bb | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-extended/images/core-image-lsb.bb > b/meta/recipes-extended/images/core-image-lsb.bb > index ed316a6..ab61c6e 100644 > --- a/meta/recipes-extended/images/core-image-lsb.bb > +++ b/meta/recipes-extended/images/core-image-lsb.bb > @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ > packagegroup-core-lsb \ > " > > -inherit core-image > +inherit core-image distro_features_check > + > +REQUIRED_DISTRO_FEATURES = "pam" I have a feeling the autobuilder builds core-image-lsb in situations where DISTRO=poky, although I could be wrong. Have you checked? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
core-image-lsb only gave a warning: "WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM won't work correctly" when the proper DISTRO was not set for it. default choice would be DISTRO = "poky-lsb", but not necessarily, depending on each custom distro. This fix will enforce the proper usage of pam as a distro feature for core-image-lsb by giving an error instead of just a warning. Fixes [YOCTO #6073] Signed-off-by: Cristian Iorga --- meta/recipes-extended/images/core-image-lsb.bb | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/recipes-extended/images/core-image-lsb.bb b/meta/recipes-extended/images/core-image-lsb.bb index ed316a6..ab61c6e 100644 --- a/meta/recipes-extended/images/core-image-lsb.bb +++ b/meta/recipes-extended/images/core-image-lsb.bb @@ -9,4 +9,6 @@ IMAGE_INSTALL = "\ packagegroup-core-lsb \ " -inherit core-image +inherit core-image distro_features_check + +REQUIRED_DISTRO_FEATURES = "pam" -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Fix for YB6073
The following changes since commit 8210928e847fda7dbc145a94372b0beaf653a4f9: yocto-bsps: remove linux-yocto 3.8 bbappend (2014-03-30 23:53:00 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ciorga/lsb-pam-enforcing http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ciorga/lsb-pam-enforcing Cristian Iorga (1): core-image-lsb: enforce pam as a needed distro feature meta/recipes-extended/images/core-image-lsb.bb | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/5] packagegroup-self-hosted: Use packagegroup-core-buildessential
Hello, BA is short for Build Appliance, and corresponds to build-appliance-image target. Like I previously said, only building BA is not a proper test. After the change that you proposed (a fine change, I might say), building images in BA is another test that needs to be performed in order to validate your change. See details here: https://www.yoctoproject.org/documentation/build-appliance-manual Regards, Cristian Iorga YP Intel Corporation -Original Message- From: Hongxu Jia [mailto:hongxu@windriver.com] Sent: Monday, March 31, 2014 11:32 AM To: Iorga, Cristian Cc: openembedded-core@lists.openembedded.org; Georgescu, Alexandru C Subject: Re: [OE-core] [PATCH 3/5] packagegroup-self-hosted: Use packagegroup-core-buildessential On 03/29/2014 12:48 AM, Iorga, Cristian wrote: > Hello all, > > This is an important patch, please make sure that BA still works correctly > after this one gets merged (including properly building an image in BA). Hi Cristian, I have built the build-appliance-image with this one merged, and everything is ok, but I could not understand what the 'BA' means, would you please explain that? Thanks, //Hongxu > Thanks, > Cristian Iorga > YP > Intel Corporation > > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Hongxu Jia > Sent: Friday, March 28, 2014 11:44 AM > To: openembedded-core@lists.openembedded.org > Cc: Wold, Saul > Subject: [OE-core] [PATCH 3/5] packagegroup-self-hosted: Use > packagegroup-core-buildessential > > From: Mark Hatle > > Instead of manually specifying build dependencies, use the > packagegroup-core-buildessential. This ensures there is only one place that > needs to be modified when toolchain items and dependencies change. > > Signed-off-by: Mark Hatle > Signed-off-by: Jeff Polk > Signed-off-by: Hongxu Jia > --- > meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 12 > +--- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git > a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb > b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb > index 5581d8e..fe49fb4 100644 > --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb > +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb > @@ -66,33 +66,23 @@ RRECOMMENDS_packagegroup-self-hosted-host-tools = > "\ > > # eglibc-utils: for rpcgen > RDEPENDS_packagegroup-self-hosted-sdk = "\ > -autoconf \ > -automake \ > -binutils \ > ccache \ > coreutils \ > -cpp \ > distcc \ > eglibc-utils \ > eglibc-gconv-ibm850 \ > file \ > findutils \ > -g++ \ > -gcc \ > intltool \ > ldd \ > less \ > libssp \ > libssp-dev \ > libssp-staticdev \ > -libstdc++ \ > -libstdc++-dev \ > -libtool \ > -make \ > mktemp \ > +packagegroup-core-buildessential \ > perl-module-re \ > perl-module-text-wrap \ > -pkgconfig \ > quilt \ > sed \ > " > -- > 1.8.1.2 > > -- > ___ > 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] pseudo-1.5.1: keep install command directory mode
From: "yanjun.zhu"
When install command sets the created directory mode, pseudo will change
the mode of the directory to 0700 incorrectly. Backport patch to fix it.
Drop PR as well.
Signed-off-by: yanjun.zhu
Signed-off-by: Kai Kang
---
.../files/pseudo-1.5.1-install-directory-mode.patch| 18 ++
meta/recipes-devtools/pseudo/pseudo_1.5.1.bb | 3 +--
2 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
diff --git
a/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
new file mode 100644
index 000..e8eaf13
--- /dev/null
+++
b/meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch
@@ -0,0 +1,18 @@
+Upstream-Status: Backport
+
+when install command sets the created directory mode, pseudo will change
+the mode of the directory to 0700 incorrectly.
+
+Signed-off-by: yanjun.zhu
+Signed-off-by: Kai Kang
+
+--- a/ports/unix/guts/mkdirat.c
b/ports/unix/guts/mkdirat.c
+@@ -25,6 +25,7 @@
+ stat_rc = base_fstatat(dirfd, path, &buf, AT_SYMLINK_NOFOLLOW);
+ #endif
+ if (stat_rc != -1) {
++ buf.st_mode = PSEUDO_DB_MODE(buf.st_mode, mode);
+ pseudo_client_op(OP_MKDIR, 0, -1, dirfd, path, &buf);
+ } else {
+ pseudo_debug(1, "mkdir of %s succeeded, but stat
failed: %s\n",
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
index bc92856..c265017 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb
@@ -1,11 +1,10 @@
require pseudo.inc
-PR = "r4"
-
SRC_URI = " \
http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0001-pseudo_has_unload-add-function.patch \
file://shutdownping.patch \
+file://pseudo-1.5.1-install-directory-mode.patch \
"
SRC_URI[md5sum] = "5ec67c7bff5fe68c56de500859c19172"
--
1.8.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] pseudo-1.5.1: keep install command directory mode
Update and resend. * Update patch header. * Drop PR. yanjun.zhu (1): pseudo-1.5.1: keep install command directory mode .../files/pseudo-1.5.1-install-directory-mode.patch| 18 ++ meta/recipes-devtools/pseudo/pseudo_1.5.1.bb | 3 +-- 2 files changed, 19 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/pseudo/files/pseudo-1.5.1-install-directory-mode.patch -- 1.8.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/5] packagegroup-self-hosted: Use packagegroup-core-buildessential
On 03/29/2014 12:48 AM, Iorga, Cristian wrote: Hello all, This is an important patch, please make sure that BA still works correctly after this one gets merged (including properly building an image in BA). Hi Cristian, I have built the build-appliance-image with this one merged, and everything is ok, but I could not understand what the 'BA' means, would you please explain that? Thanks, //Hongxu Thanks, Cristian Iorga YP Intel Corporation -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Hongxu Jia Sent: Friday, March 28, 2014 11:44 AM To: openembedded-core@lists.openembedded.org Cc: Wold, Saul Subject: [OE-core] [PATCH 3/5] packagegroup-self-hosted: Use packagegroup-core-buildessential From: Mark Hatle Instead of manually specifying build dependencies, use the packagegroup-core-buildessential. This ensures there is only one place that needs to be modified when toolchain items and dependencies change. Signed-off-by: Mark Hatle Signed-off-by: Jeff Polk Signed-off-by: Hongxu Jia --- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index 5581d8e..fe49fb4 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -66,33 +66,23 @@ RRECOMMENDS_packagegroup-self-hosted-host-tools = "\ # eglibc-utils: for rpcgen RDEPENDS_packagegroup-self-hosted-sdk = "\ -autoconf \ -automake \ -binutils \ ccache \ coreutils \ -cpp \ distcc \ eglibc-utils \ eglibc-gconv-ibm850 \ file \ findutils \ -g++ \ -gcc \ intltool \ ldd \ less \ libssp \ libssp-dev \ libssp-staticdev \ -libstdc++ \ -libstdc++-dev \ -libtool \ -make \ mktemp \ +packagegroup-core-buildessential \ perl-module-re \ perl-module-text-wrap \ -pkgconfig \ quilt \ sed \ " -- 1.8.1.2 -- ___ 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] lsbtest: fix comparison bashism
On Sun, 2014-03-30 at 18:55 -0400, Trevor Woerner wrote: > On 03/11/14 11:40, Stefan Stanacar wrote: > > == is a bashism use = instead. > > But the first line of this script is: > #/bin/bash > > Shouldn't a bash script be allowed to have bash-isms??! I was referring to the recipe which shouldn't have bash-isms. Yes, the recipe installs a script which has /bin/bash, but I didn't saw any harm in fixing that too. Cheers, Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] [Dora] eglibc 2.18: powerpc: Fix time related syscalls
Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken from upstream glibc. See credits in patch header. The effect is that some time related system calls returns nothing or garbage. Fix tested on PowerPC e300c3. Eglibc 2.17 does not have this issue and the patches are already part of 2.19. Signed-off-by: Mats Karrman --- .../ppc-fix-time-related-syscalls.patch| 227 meta/recipes-core/eglibc/eglibc_2.18.bb|1 + 2 files changed, 228 insertions(+) create mode 100644 meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch V3: ...and moved it to patch instead of commit header. V2: Added upstream status. diff --git a/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch new file mode 100644 index 000..319b826 --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch @@ -0,0 +1,227 @@ +Upstream-Status: Backport + +Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken +from upstream glibc. Eglibc 2.17 does not have this issue and the patches are +already part of 2.19. +This compilation includes the following committs: + + +PowerPC: Fix vDSO missing ODP entries + +author Adhemerval Zanella + Thu, 7 Nov 2013 11:34:22 + (05:34 -0600) + +This patch fixes the vDSO symbol used directed in IFUNC resolver where +they do not have an associated ODP entry leading to undefined behavior +in some cases. It adds an artificial OPD static entry to such cases +and set its TOC to non 0 to avoid triggering lazy resolutions. + + +Update copyright notices with scripts/update-copyrights + +author Allan McRae + Wed, 1 Jan 2014 11:03:15 + (21:03 +1000) + +((Only for files otherwise touched by this patch)) + + +PowerPC: Fix ftime gettimeofday internal call returning bogus data + +author Adhemerval Zanella + Thu, 16 Jan 2014 12:53:18 + (06:53 -0600) + +This patches fixes BZ#16430 by setting a different symbol for internal +GLIBC calls that points to ifunc resolvers. For PPC32, if the symbol +is defined as hidden (which is the case for gettimeofday and time) the +compiler will create local branches (symbol@local) and linker will not +create PLT calls (required for IFUNC). This will leads to internal symbol +calling the IFUNC resolver instead of the resolved symbol. +For PPC64 this behavior does not occur because a call to a function in +another translation unit might use a different toc pointer thus requiring +a PLT call. + + +PowerPC: Fix gettimeofday ifunc selection + +author Adhemerval Zanella + Mon, 20 Jan 2014 18:29:51 + (12:29 -0600) + +The IFUNC selector for gettimeofday runs before _libc_vdso_platform_setup where +__vdso_gettimeofday is set. The selector then sets __gettimeofday (the internal +version used within GLIBC) to use the system call version instead of the vDSO one. +This patch changes the check if vDSO is available to get its value directly +instead of rely on __vdso_gettimeofday. + +This patch changes it by getting the vDSO value directly. + +It fixes BZ#16431. + + +--- +diff -pruN libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +--- libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +@@ -1,5 +1,5 @@ + /* Resolve function pointers to VDSO functions. +- Copyright (C) 2005-2013 Free Software Foundation, Inc. ++ Copyright (C) 2005-2014 Free Software Foundation, Inc. +This file is part of the GNU C Library. + +The GNU C Library is free software; you can redistribute it and/or +@@ -34,12 +34,32 @@ extern void *__vdso_getcpu; + + extern void *__vdso_time; + +-/* This macro is needed for PPC64 to return a skeleton OPD entry of a vDSO +- symbol. This works because _dl_vdso_vsym always return the function +- address, and no vDSO symbols use the TOC or chain pointers from the OPD +- so we can allow them to be garbage. */ + #if defined(__PPC64__) || defined(__powerpc64__) +-#define VDSO_IFUNC_RET(value) ((void *) &(value)) ++/* The correct solution is for _dl_vdso_vsym to return the address of the OPD ++ for the kernel VDSO function. That address would then be stored in the ++ __vdso_* variables and returned as the result of the IFUNC resolver function. ++ Yet, the kernel does not contain any OPD entries for the VDSO functions ++ (incomplete implementation). However, PLT relocations for IFUNCs still expect ++ the address of an OPD to be returned from the IFUNC resolver function (since ++ PLT entries on PPC64 are just copies of OPDs). The solution for now is to ++ create an artificial static OPD for each VDSO function returned by a resolver ++ function. The TOC value is set to a non-zero value to avoid triggering lazy ++ symbol res
