[OE-core] [PATCH] cml1: correct diffconfig output format
If used with some packages using kconfig mechanism, the diffconfig
command generates wrong output format. Diff provides all options to
format the output correctly. This method formats as intended, is more
robust and works with the merge_config.h script from yocto-kernel-tools.
Signed-off-by: Stefan Müller-Klieser
---
meta/classes/cml1.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 34c0c4e..0d4b10b 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -58,7 +58,7 @@ python do_diffconfig() {
bb.fatal("No config files found. Did you do menuconfig ?\n%s" % e)
if isdiff:
-statement = 'diff -Nurp ' + configorig + ' ' + config + '| sed -n
"s/^\+//p" >' + fragment
+statement = 'diff --unchanged-line-format= --old-line-format=
--new-line-format="%L"' + configorig + ' ' + config + '>' + fragment
subprocess.call(statement, shell=True)
shutil.copy(configorig, config)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
Op 28 jul. 2014, om 08:49 heeft Huang, Jie (Jackie)
het volgende geschreven:
>
>
>> -Original Message-
>> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
>> Sent: Monday, July 28, 2014 2:30 PM
>> To: Huang, Jie (Jackie)
>> Cc: OE-core; Richard Purdie
>> Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
>>
>>
>> Op 25 jul. 2014, om 12:05 heeft jackie.hu...@windriver.com het volgende
>> geschreven:
>>
>>> From: Jackie Huang
>>>
>>> All dev related items should be packaged in the core PN-dev package
>>> not in seperate packages.
>>
>> What's the upgrade path here for image and users that have 'alsa-dev'
>> installed? Looks like there are
>
> My patch is removing 'alsa-dev' and all related files goes into '${PN}-dev'
> (PN=alsa-lib here), so users need to install
> alsa-lib-dev instead of alsa-dev.
*sigh* So you have no upgrade path for situations where 'alsa-dev' is already
installed or listed in a packagegroup or image. Worse, you don't even
understand the problem :/
>
>> now 2 conflicting packages, 'alsa-dev' in the feeds and 'alsa-lib-dev' on
>> OE, without and
>
> Only 'alsa-lib-dev' now with my patch, so no conflicts.
Hahahahahaha you are really funny.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
On Mon, 2014-07-28 at 10:51 +0200, Koen Kooi wrote:
> Op 28 jul. 2014, om 08:49 heeft Huang, Jie (Jackie)
> het volgende geschreven:
> >> -Original Message-
> >> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
> >> Sent: Monday, July 28, 2014 2:30 PM
> >> To: Huang, Jie (Jackie)
> >> Cc: OE-core; Richard Purdie
> >> Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
> >>
> >>
> >> Op 25 jul. 2014, om 12:05 heeft jackie.hu...@windriver.com het volgende
> >> geschreven:
> >>
> >>> From: Jackie Huang
> >>>
> >>> All dev related items should be packaged in the core PN-dev package
> >>> not in seperate packages.
> >>
> >> What's the upgrade path here for image and users that have 'alsa-dev'
> >> installed? Looks like there are
> >
> > My patch is removing 'alsa-dev' and all related files goes into '${PN}-dev'
> > (PN=alsa-lib here), so users need to install
> > alsa-lib-dev instead of alsa-dev.
>
> *sigh* So you have no upgrade path for situations where 'alsa-dev' is already
> installed or listed in a packagegroup or image. Worse, you don't even
> understand the problem :/
>
> >
> >> now 2 conflicting packages, 'alsa-dev' in the feeds and 'alsa-lib-dev' on
> >> OE, without and
> >
> > Only 'alsa-lib-dev' now with my patch, so no conflicts.
>
> Hahahahahaha you are really funny.
I appreciate there is a problem here and we need to fix that. There is
also an education issue, people who don't know much about it don't
appreciate the struggles of someone maintaining package feeds.
Perhaps someone could write a short section for the docs about the
issues here? In future when this kind of problem comes up, we can then
at least point at the manual section to explain it.
Currently, most docs come from the "same old people", I'm partly writing
this to remind people that others can submit them and that they can help
massively in educating people.
They don't even need to be proper patches against the docs, just write a
few paragraphs, send it Scott Rifenbark's way and he can usually do
something with it. He tends to reword things so the manual has a
consistent tone and style anyway so it needn't be word perfect either,
its the content that matters (and that is the part Scott cannot do).
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
>
> Op 28 jul. 2014, om 08:49 heeft Huang, Jie (Jackie)
> het volgende
> geschreven:
>
> >
> >
> >> -Original Message-
> >> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
> >> Sent: Monday, July 28, 2014 2:30 PM
> >> To: Huang, Jie (Jackie)
> >> Cc: OE-core; Richard Purdie
> >> Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev
> >> packages
> >>
> >>
> >> Op 25 jul. 2014, om 12:05 heeft jackie.hu...@windriver.com het volgende
> >> geschreven:
> >>
> >>> From: Jackie Huang
> >>>
> >>> All dev related items should be packaged in the core PN-dev package
> >>> not in seperate packages.
> >>
> >> What's the upgrade path here for image and users that have 'alsa-dev'
> >> installed? Looks like there are
> >
> > My patch is removing 'alsa-dev' and all related files goes into
> > '${PN}-dev' (PN=alsa-lib here), so users need to install alsa-lib-dev
> > instead of alsa-dev.
>
> *sigh* So you have no upgrade path for situations where 'alsa-dev' is already
> installed or listed in a
> packagegroup or image. Worse, you don't even understand the problem :/
I see your point, I did grep on oe-core and meta-oe and didn't find any
evidence that 'alsa-dev' is installed or listed
In a packagegroup or image, so I thought it's safe to remove without
RREPLACES/RPROVIDES in place, sorry that I did
a wrong assumption, I will add a RPROVIDES for this, thanks!
Thanks,
Jackie
>
> >
> >> now 2 conflicting packages, 'alsa-dev' in the feeds and
> >> 'alsa-lib-dev' on OE, without and
> >
> > Only 'alsa-lib-dev' now with my patch, so no conflicts.
>
> Hahahahahaha you are really funny.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Monday, July 28, 2014 5:25 PM
> To: Koen Kooi
> Cc: Huang, Jie (Jackie); OE-core; RIFENBARK, SCOTT
> Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
>
> On Mon, 2014-07-28 at 10:51 +0200, Koen Kooi wrote:
> > Op 28 jul. 2014, om 08:49 heeft Huang, Jie (Jackie)
> > het volgende
> geschreven:
> > >> -Original Message-
> > >> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
> > >> Sent: Monday, July 28, 2014 2:30 PM
> > >> To: Huang, Jie (Jackie)
> > >> Cc: OE-core; Richard Purdie
> > >> Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev
> > >> packages
> > >>
> > >>
> > >> Op 25 jul. 2014, om 12:05 heeft jackie.hu...@windriver.com het volgende
> > >> geschreven:
> > >>
> > >>> From: Jackie Huang
> > >>>
> > >>> All dev related items should be packaged in the core PN-dev
> > >>> package not in seperate packages.
> > >>
> > >> What's the upgrade path here for image and users that have
> > >> 'alsa-dev' installed? Looks like there are
> > >
> > > My patch is removing 'alsa-dev' and all related files goes into
> > > '${PN}-dev' (PN=alsa-lib here), so users need to install alsa-lib-dev
> > > instead of alsa-dev.
> >
> > *sigh* So you have no upgrade path for situations where 'alsa-dev' is
> > already installed or listed in a packagegroup or image. Worse, you
> > don't even understand the problem :/
> >
> > >
> > >> now 2 conflicting packages, 'alsa-dev' in the feeds and
> > >> 'alsa-lib-dev' on OE, without and
> > >
> > > Only 'alsa-lib-dev' now with my patch, so no conflicts.
> >
> > Hahahahahaha you are really funny.
>
> I appreciate there is a problem here and we need to fix that. There is also
> an education issue, people
> who don't know much about it don't appreciate the struggles of someone
> maintaining package feeds.
Sorry that I got misunderstanding about the commets since I didn't know much
the issue, I appreciate that
and will send another patch to fix it since this one is already merged.
Thanks,
Jackie
>
> Perhaps someone could write a short section for the docs about the issues
> here? In future when this
> kind of problem comes up, we can then at least point at the manual section to
> explain it.
>
> Currently, most docs come from the "same old people", I'm partly writing this
> to remind people that
> others can submit them and that they can help massively in educating people.
>
> They don't even need to be proper patches against the docs, just write a few
> paragraphs, send it Scott
> Rifenbark's way and he can usually do something with it. He tends to reword
> things so the manual has
> a consistent tone and style anyway so it needn't be word perfect either, its
> the content that matters
> (and that is the part Scott cannot do).
>
> Cheers,
>
> Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] barebox: Add recipe
barebox (formerly known as u-boot-v2) is a bootloader that inherits the
best of U-Boot and the Linux kernel. This commit adds the possibility to
use it as a virtual/bootloader instead of U-Boot.
Signed-off-by: David Vincent
---
meta/recipes-bsp/barebox/barebox.inc | 73 +
meta/recipes-bsp/barebox/barebox_2014.07.0.bb | 15 +
2 files changed, 88 insertions(+)
create mode 100644 meta/recipes-bsp/barebox/barebox.inc
create mode 100644 meta/recipes-bsp/barebox/barebox_2014.07.0.bb
diff --git a/meta/recipes-bsp/barebox/barebox.inc
b/meta/recipes-bsp/barebox/barebox.inc
new file mode 100644
index 000..68aeb68
--- /dev/null
+++ b/meta/recipes-bsp/barebox/barebox.inc
@@ -0,0 +1,73 @@
+SUMMARY = "The Barebox Bootloader"
+DESCRIPTION = "Barebox (formerly known as u-boot-v2) is a bootloader that
inherits the best of U-Boot and the Linux kernel: The size and look-and-feel of
u-boot, with driver model and lots of design concepts from the kernel."
+HOMEPAGE = "http://www.barebox.org";
+SECTION = "bootloaders"
+PROVIDES = "virtual/bootloader"
+
+inherit cml1 deploy kernel-arch
+
+EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc
${TOOLCHAIN_OPTIONS}"'
+
+BAREBOX_BINARY ?= "barebox.bin"
+BAREBOX_IMAGE ?= "barebox-${MACHINE}-${PV}-${PR}.bin"
+BAREBOX_SYMLINK ?= "barebox-${MACHINE}.bin"
+
+do_configure () {
+ # Copy defconfig to .config if .config does not exist. This allows
+ # recipes to manage the .config themselves in do_configure_prepend().
+ if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
+ cp "${WORKDIR}/defconfig" "${B}/.config"
+ fi
+
+ # Use board default defconfig if .config does not exist. This allows
+ # recipes to manage the .config themselves in do_configure_prepend().
+ if [ ! -f "${B}/.config" ]; then
+ oe_runmake_call ${BAREBOX_TARGET}
+ fi
+
+ cml1_do_configure
+}
+
+do_compile () {
+ if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold',
'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
+ sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g'
${S}/Makefile
+ fi
+
+ unset CFLAGS CPPFLAGS LDFLAGS
+ oe_runmake
+}
+
+do_install () {
+ install -d ${D}/boot
+ install ${S}/barebox-flash-image ${D}/boot/${BAREBOX_IMAGE}
+ ln -sf ${BAREBOX_IMAGE} ${D}/boot/${BAREBOX_BINARY}
+
+ # Install target tools if available
+ install -d ${D}${sbindir}
+
+ if [ -e ${WORKDIR}/scripts/bareboxenv-target ]; then
+ install -m 0755 ${WORKDIR}/scripts/bareboxenv-target
${D}${sbindir}/bareboxenv
+ fi
+
+ if [ -e ${WORKDIR}/scripts/bareboxcrc32-target ]; then
+ install -m 0755 ${WORKDIR}/scripts/bareboxcrc32-target
${D}${sbindir}/bareboxcrc32
+ fi
+
+ if [ -e ${WORKDIR}/scripts/kernel-install-target ]; then
+ install -m 0755 ${WORKDIR}/scripts/kernel-install-target
${D}${sbindir}/kernel-install
+ fi
+}
+
+FILES_${PN} = "/boot ${sbindir}"
+
+do_deploy () {
+ install -d ${DEPLOYDIR}
+ install ${S}/barebox-flash-image ${DEPLOYDIR}/${BAREBOX_IMAGE}
+
+ cd ${DEPLOYDIR}
+ rm -f ${BAREBOX_BINARY} ${BAREBOX_SYMLINK}
+ ln -sf ${BAREBOX_IMAGE} ${BAREBOX_SYMLINK}
+ ln -sf ${BAREBOX_IMAGE} ${BAREBOX_BINARY}
+}
+
+addtask deploy before do_build after do_compile
diff --git a/meta/recipes-bsp/barebox/barebox_2014.07.0.bb
b/meta/recipes-bsp/barebox/barebox_2014.07.0.bb
new file mode 100644
index 000..6adbff4
--- /dev/null
+++ b/meta/recipes-bsp/barebox/barebox_2014.07.0.bb
@@ -0,0 +1,15 @@
+require barebox.inc
+
+# To build barebox for your machine, provide the following lines in your
machine
+# config, replacing the assignments as appropriate for your machine.
+# BAREBOX_MACHINE = "sandbox"
+# BAREBOX_TARGET = "sandbox_defconfig"
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=057bf9e50e1ca857d0eb97bfe4ba8e5d"
+
+SRC_URI = "http://www.barebox.org/download/${PN}-${PV}.tar.bz2";
+SRC_URI[md5sum] = "f3a93950777916d4b1c2cd366aec8d91"
+SRC_URI[sha256sum] =
"6dca5c78de8565a15aaa404edbf1bc4663415f0dc69e094f3b621636876285f2"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] barebox: Add recipe
On Mon, 2014-07-28 at 11:55 +0200, David Vincent wrote: > barebox (formerly known as u-boot-v2) is a bootloader that inherits the > best of U-Boot and the Linux kernel. This commit adds the possibility to > use it as a virtual/bootloader instead of U-Boot. > > Signed-off-by: David Vincent > --- > meta/recipes-bsp/barebox/barebox.inc | 73 > + > meta/recipes-bsp/barebox/barebox_2014.07.0.bb | 15 + > 2 files changed, 88 insertions(+) > create mode 100644 meta/recipes-bsp/barebox/barebox.inc > create mode 100644 meta/recipes-bsp/barebox/barebox_2014.07.0.bb I have to admit I don't know a lot about this. To make it into OE-Core we need some kind of story about why its necessary and commonly used. Are there a number of BSPs using this? Can you give some background to why this is needed? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] State of bitbake world, Failed tasks 2014-07-28
http://www.openembedded.org/wiki/Bitbake_World_Status
This time it was building without any sstate-cache, so we have complete qa.log
files
(they are included in log dir)
Here are some stats:
$ cat log.world.2014072*/qa.log | sort -u | grep -c 'build-deps'
166
$ cat log.world.2014072*/qa.log | sort -u | grep -c 'textrel'
18
$ cat log.world.2014072*/qa.log | sort -u | grep -c 'unknown-configure-option'
21
$ cat log.world.2014072*/qa.log | sort -u | grep -c 'already-stripped'
4
$ cat log.world.2014072*/qa.log | sort -u | grep -c 'version-going-backwards'
23
== Failed tasks 2014-07-28 ==
=== common (2) ===
*
meta-openembedded/meta-multimedia/recipes-multimedia/openal/openal-soft_1.15.1.bb,
do_compile
*
openembedded-core/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb,
do_compile
=== common-x86 (3) ===
* meta-browser/recipes-browser/chromium/chromium_35.0.1916.114.bb,
do_compile
* meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile
*
meta-openembedded/meta-oe/recipes-devtools/concurrencykit/concurrencykit_git.bb,
do_compile
=== qemuarm (0) ===
=== qemux86 (0) ===
=== qemux86_64 (1) ===
* meta-qt5/recipes-qt/qt5/qtwebengine_git.bb, do_compile
=== Number of failed tasks ===
{| class=wikitable
|-
||qemuarm ||2
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140725_170016.log/||http://errors.yoctoproject.org:80/Errors/Search/1/1474/
|-
||qemux86 ||5
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140726_131244.log/||
|-
||qemux86_64||6
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140727_084254.log/||
|}
--
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] gmp: redefine a function
From: Roy Li
redefine a function to make it be able to work on mips64 64BIT ABI
Signed-off-by: Roy Li
---
.../gmp/gmp-4.2.1/reimplement_umul_ppmm.patch | 39
meta/recipes-support/gmp/gmp_4.2.1.bb |1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-support/gmp/gmp-4.2.1/reimplement_umul_ppmm.patch
diff --git a/meta/recipes-support/gmp/gmp-4.2.1/reimplement_umul_ppmm.patch
b/meta/recipes-support/gmp/gmp-4.2.1/reimplement_umul_ppmm.patch
new file mode 100644
index 000..739d88a
--- /dev/null
+++ b/meta/recipes-support/gmp/gmp-4.2.1/reimplement_umul_ppmm.patch
@@ -0,0 +1,39 @@
+[PATCH] reimplement umul_ppmm to make it be able to building on mips64 64bit
ABI
+
+Upstream-Status: Pending[This version was not maintained by upstream, larger
versions have been fixed]
+
+Signed-off-by: Roy.Li
+---
+ longlong.h | 14 --
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/longlong.h b/longlong.h
+index b53fbee..faa845a 100644
+--- a/longlong.h
b/longlong.h
+@@ -1024,10 +1024,20 @@ extern UWtype __MPN(udiv_qrnnd) _PROTO ((UWtype *,
UWtype, UWtype, UWtype));
+ #endif /* __mips */
+
+ #if (defined (__mips) && __mips >= 3) && W_TYPE_SIZE == 64
+-#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7
++#if __GMP_GNUC_PREREQ (4,4)
++#define umul_ppmm(w1, w0, u, v) \
++ do {\
++typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
++__ll_UTItype __ll = (__ll_UTItype)(u) * (v); \
++w1 = __ll >> 64; \
++w0 = __ll;\
++ } while (0)
++#endif
++#if !defined (umul_ppmm) && __GMP_GNUC_PREREQ (2,7)
+ #define umul_ppmm(w1, w0, u, v) \
+ __asm__ ("dmultu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
+-#else
++#endif
++#if !defined (umul_ppmm)
+ #define umul_ppmm(w1, w0, u, v) \
+ __asm__ ("dmultu %2,%3\n\tmflo %0\n\tmfhi %1"
\
+ : "=d" (w0), "=d" (w1) : "d" (u), "d" (v))
+--
+1.9.1
+
diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb
b/meta/recipes-support/gmp/gmp_4.2.1.bb
index 69ad0ca..216ee41 100644
--- a/meta/recipes-support/gmp/gmp_4.2.1.bb
+++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
@@ -12,6 +12,7 @@ PR = "r2"
SRC_URI = "${GNU_MIRROR}/gmp/${BP}.tar.bz2 \
file://disable-stdc.patch \
file://gmp_fix_for_automake-1.12.patch \
+ file://reimplement_umul_ppmm.patch \
"
SRC_URI[md5sum] = "091c56e0e1cca6b09b17b69d47ef18e3"
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/1] systemd: upgrade to 215
The following changes since commit 58f08a96764094189b5aaf3cc8b4cc0c95e23409:
gst-ffmpeg: Add CVE patches (2014-07-23 21:57:04 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd_215
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd_215
Chen Qi (1):
systemd: upgrade to 215
.../systemd/systemd/systemd-older-kernel.patch | 56
.../systemd/{systemd_213.bb => systemd_215.bb} | 12 +++--
2 files changed, 7 insertions(+), 61 deletions(-)
delete mode 100644 meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
rename meta/recipes-core/systemd/{systemd_213.bb => systemd_215.bb} (97%)
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/1] systemd: upgrade to 215
Upgrade systemd from 213 to 215.
systemd-older-kernel.patch is removed as it's fixed in 215.
The files under /usr/lib/sysusers.d/ are also added to CONFFILES.
Signed-off-by: Chen Qi
---
.../systemd/systemd/systemd-older-kernel.patch | 56
.../systemd/{systemd_213.bb => systemd_215.bb} | 12 +++--
2 files changed, 7 insertions(+), 61 deletions(-)
delete mode 100644 meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
rename meta/recipes-core/systemd/{systemd_213.bb => systemd_215.bb} (97%)
diff --git a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
b/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
deleted file mode 100644
index 18b50e7..000
--- a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 6109f02dcc4f2d7a461c5772bab494f5753a2203 Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Thu, 29 May 2014 08:09:07 +
-Subject: [PATCH] rtnl-types.c: check IFLA_VLAN_PROTOCOL
-
-The older kernel's linux/if_link.h doesn't have IFLA_VLAN_PROTOCOL, we need
-check whether it has been defined or not.
-
-The maintainer said that he would fix it:
-
-http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/18200
-
-Also we need redefine IFLA_MAX from 34 to 35 when define IFLA_CARRIER,
-otherwise there would be error:
-
-| src/libsystemd/sd-rtnl/rtnl-types.c:233:9: error: array index in initializer
exceeds array bounds
-| [IFLA_CARRIER] = { .type = NLA_U8 },
-
-Upstream-Status: Pending
-
-Signed-off-by: Robert Yang
- src/libsystemd/sd-rtnl/rtnl-types.c | 2 ++
- src/shared/missing.h| 2 ++
- 2 files changed, 4 insertions(+)
-
-diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
-index 44ac5ec..ab6161f 100644
a/src/libsystemd/sd-rtnl/rtnl-types.c
-+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
-@@ -67,7 +67,9 @@ static const NLType
rtnl_link_info_data_vlan_types[IFLA_VLAN_MAX + 1] = {
- [IFLA_VLAN_EGRESS_QOS] = { .type = NLA_NESTED },
- [IFLA_VLAN_INGRESS_QOS] = { .type = NLA_NESTED },
- */
-+#ifdef IFLA_VLAN_PROTOCOL
- [IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
-+#endif
- };
-
- static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
-diff --git a/src/shared/missing.h b/src/shared/missing.h
-index d5ec2f8..732853f 100644
a/src/shared/missing.h
-+++ b/src/shared/missing.h
-@@ -94,6 +94,8 @@
-
- #ifndef IFLA_CARRIER
- #define IFLA_CARRIER 33
-+ #undef IFLA_MAX
-+ #define IFLA_MAX 35
- #ifndef IFLA_NUM_RX_QUEUES
- #define IFLA_NUM_RX_QUEUES 32
- #ifndef IFLA_NUM_TX_QUEUES
---
-1.8.3.4
-
diff --git a/meta/recipes-core/systemd/systemd_213.bb
b/meta/recipes-core/systemd/systemd_215.bb
similarity index 97%
rename from meta/recipes-core/systemd/systemd_213.bb
rename to meta/recipes-core/systemd/systemd_215.bb
index 5de7cdc..a8f0c64 100644
--- a/meta/recipes-core/systemd/systemd_213.bb
+++ b/meta/recipes-core/systemd/systemd_215.bb
@@ -17,9 +17,9 @@ SECTION = "base/shell"
inherit gtk-doc useradd pkgconfig autotools perlnative update-rc.d
update-alternatives qemu systemd ptest
-SRCREV = "c9679c652b3c31f2510e8805d81630680ebc7e95"
+SRCREV = "252ff40a3827b4e8e62e03a5e2f80da3fe02bee6"
-PV = "213+git${SRCPV}"
+PV = "215+git${SRCPV}"
SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=git \
file://binfmt-install.patch \
@@ -35,8 +35,7 @@ SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=
file://00-create-volatile.conf \
file://init \
file://run-ptest \
- file://systemd-older-kernel.patch \
- "
+ "
S = "${WORKDIR}/git"
@@ -198,7 +197,9 @@ RRECOMMENDS_${PN}-vconsole-setup = "kbd kbd-consolefonts"
CONFFILES_${PN} = "${sysconfdir}/systemd/journald.conf \
${sysconfdir}/systemd/logind.conf \
${sysconfdir}/systemd/system.conf \
-${sysconfdir}/systemd/user.conf"
+${sysconfdir}/systemd/user.conf \
+${exec_prefix}/lib/sysusers.d/systemd.conf \
+${exec_prefix}/lib/sysusers.d/basic.conf"
FILES_${PN} = " ${base_bindir}/* \
${datadir}/bash-completion \
@@ -231,6 +232,7 @@ FILES_${PN} = " ${base_bindir}/* \
${exec_prefix}/lib/systemd \
${exec_prefix}/lib/modules-load.d \
${exec_prefix}/lib/sysctl.d \
+${exec_prefix}/lib/sysusers.d \
${localstatedir} \
/lib/udev/rules.d/70-uaccess.rules \
/lib/udev/rules.d/71-seat.rules \
--
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] libx11: Add missing NULL check
On 28 July 2014 00:05, Drew Moseley wrote: > +Upstream-Status: Submitted > [https://bugs.freedesktop.org/show_bug.cgi?id=81822] FWIW you generally get better responses from Xorg if you mail the list with patches. If the patch goes nowhere then I suggest mailing the patch to the list directly instead. Also XOpenIM documentation says "XOpenIM returns NULL if no input method could be opened" so arguably this should be fixed in mplayer (and guarded in libX11). Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] barebox: Add recipe
Hi David,
Le Mon, 28 Jul 2014 11:55:04 +0200,
David Vincent a écrit :
>
> barebox (formerly known as u-boot-v2) is a bootloader that inherits the
> best of U-Boot and the Linux kernel. This commit adds the possibility to
> use it as a virtual/bootloader instead of U-Boot.
>
> Signed-off-by: David Vincent
> ---
> meta/recipes-bsp/barebox/barebox.inc | 73
> +
> meta/recipes-bsp/barebox/barebox_2014.07.0.bb | 15 +
> 2 files changed, 88 insertions(+)
> create mode 100644 meta/recipes-bsp/barebox/barebox.inc
> create mode 100644 meta/recipes-bsp/barebox/barebox_2014.07.0.bb
>
> diff --git a/meta/recipes-bsp/barebox/barebox.inc
> b/meta/recipes-bsp/barebox/barebox.inc
> new file mode 100644
> index 000..68aeb68
> --- /dev/null
> +++ b/meta/recipes-bsp/barebox/barebox.inc
> @@ -0,0 +1,73 @@
> +SUMMARY = "The Barebox Bootloader"
> +DESCRIPTION = "Barebox (formerly known as u-boot-v2) is a bootloader that
> inherits the best of U-Boot and the Linux kernel: The size and look-and-feel
> of u-boot, with driver model and lots of design concepts from the kernel."
> +HOMEPAGE = "http://www.barebox.org";
> +SECTION = "bootloaders"
> +PROVIDES = "virtual/bootloader"
> +
> +inherit cml1 deploy kernel-arch
> +
> +EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc
> ${TOOLCHAIN_OPTIONS}"'
> +
> +BAREBOX_BINARY ?= "barebox.bin"
> +BAREBOX_IMAGE ?= "barebox-${MACHINE}-${PV}-${PR}.bin"
> +BAREBOX_SYMLINK ?= "barebox-${MACHINE}.bin"
> +
> +do_configure () {
> + # Copy defconfig to .config if .config does not exist. This allows
> + # recipes to manage the .config themselves in do_configure_prepend().
> + if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
> + cp "${WORKDIR}/defconfig" "${B}/.config"
> + fi
> +
> + # Use board default defconfig if .config does not exist. This allows
> + # recipes to manage the .config themselves in do_configure_prepend().
> + if [ ! -f "${B}/.config" ]; then
> + oe_runmake_call ${BAREBOX_TARGET}
> + fi
> +
> + cml1_do_configure
> +}
> +
> +do_compile () {
> + if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold',
> 'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
> + sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g'
> ${S}/Makefile
> + fi
> +
I had to add that a few year ago : is that still needed ?
> + unset CFLAGS CPPFLAGS LDFLAGS
> + oe_runmake
> +}
> +
> +do_install () {
> + install -d ${D}/boot
> + install ${S}/barebox-flash-image ${D}/boot/${BAREBOX_IMAGE}
> + ln -sf ${BAREBOX_IMAGE} ${D}/boot/${BAREBOX_BINARY}
> +
> + # Install target tools if available
> + install -d ${D}${sbindir}
> +
> + if [ -e ${WORKDIR}/scripts/bareboxenv-target ]; then
> + install -m 0755 ${WORKDIR}/scripts/bareboxenv-target
> ${D}${sbindir}/bareboxenv
> + fi
> +
> + if [ -e ${WORKDIR}/scripts/bareboxcrc32-target ]; then
> + install -m 0755 ${WORKDIR}/scripts/bareboxcrc32-target
> ${D}${sbindir}/bareboxcrc32
> + fi
> +
> + if [ -e ${WORKDIR}/scripts/kernel-install-target ]; then
> + install -m 0755 ${WORKDIR}/scripts/kernel-install-target
> ${D}${sbindir}/kernel-install
> + fi
> +}
> +
> +FILES_${PN} = "/boot ${sbindir}"
Why not splitting the tools in their own package so that we can have
the tools on the target without having the binary in /boot ?
> +
> +do_deploy () {
> + install -d ${DEPLOYDIR}
> + install ${S}/barebox-flash-image ${DEPLOYDIR}/${BAREBOX_IMAGE}
> +
Why don't you use $BAREBOX_BINARY instead of hardcoding
barebox-flash-image which won't work on old versions of barebox where
barebox's binary is named barebox.bin ?
Best regards,
Eric
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Fwd: [PATCH] barebox: Add recipe
Sorry, the patch alone was maybe a little harsh, I should have submitted it as a RFC. For me, this recipe was needed because I don't use u-boot as the bootloader for my custom board but barebox. More generically, I know that the meta-fsl-arm has also a recipe for barebox and since my board was not based on a Freescale MPU but an Atmel one, I thought that the work could be shared by the two layers in oe-core or, at least, in meta-oe instead of being also redeveloped in meta-atmel or another BSP layer. Since barebox also supports many architectures like ARM, MIPS, Blackfin,... and many vendors like Atmel, Freescale, TI,... I think it provides a good alternative for the 'virtual/bootloader' task. People who want to use it should not put more effort than what they need to do for u-boot currently. I've cc'ed the barebox mailing list for more technical details if needed. Greetings, David 2014-07-28 12:23 GMT+02:00 Richard Purdie : > On Mon, 2014-07-28 at 11:55 +0200, David Vincent wrote: >> barebox (formerly known as u-boot-v2) is a bootloader that inherits the >> best of U-Boot and the Linux kernel. This commit adds the possibility to >> use it as a virtual/bootloader instead of U-Boot. >> >> Signed-off-by: David Vincent >> --- >> meta/recipes-bsp/barebox/barebox.inc | 73 >> + >> meta/recipes-bsp/barebox/barebox_2014.07.0.bb | 15 + >> 2 files changed, 88 insertions(+) >> create mode 100644 meta/recipes-bsp/barebox/barebox.inc >> create mode 100644 meta/recipes-bsp/barebox/barebox_2014.07.0.bb > > I have to admit I don't know a lot about this. To make it into OE-Core > we need some kind of story about why its necessary and commonly used. > Are there a number of BSPs using this? Can you give some background to > why this is needed? > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libav: fix PACKAGECONFIG for theora and libvorbis
Switches must not be in EXTRA_OECONF anymore.
Signed-off-by: Matthieu Crapet
---
meta/recipes-multimedia/libav/libav.inc | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-multimedia/libav/libav.inc
b/meta/recipes-multimedia/libav/libav.inc
index 1d617a2..5c327df 100644
--- a/meta/recipes-multimedia/libav/libav.inc
+++ b/meta/recipes-multimedia/libav/libav.inc
@@ -60,8 +60,6 @@ EXTRA_OECONF = " \
--enable-avserver \
--enable-avplay \
--ld="${CCLD}" \
---enable-libtheora \
---enable-libvorbis \
--arch=${TARGET_ARCH} \
--target-os="linux" \
--enable-cross-compile \
--
2.0.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libav: fix PACKAGECONFIG for theora and libvorbis
Hi, Please take this bugfix patch first, then we could arrange the LICENSE change issue later. Regards, Matthieu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] barebox: Add recipe
Hi Eric,
2014-07-28 13:58 GMT+02:00 Eric Bénard :
> Hi David,
>
> Le Mon, 28 Jul 2014 11:55:04 +0200,
> David Vincent a écrit :
>
>>
>> barebox (formerly known as u-boot-v2) is a bootloader that inherits the
>> best of U-Boot and the Linux kernel. This commit adds the possibility to
>> use it as a virtual/bootloader instead of U-Boot.
>>
>> Signed-off-by: David Vincent
>> ---
>> meta/recipes-bsp/barebox/barebox.inc | 73
>> +
>> meta/recipes-bsp/barebox/barebox_2014.07.0.bb | 15 +
>> 2 files changed, 88 insertions(+)
>> create mode 100644 meta/recipes-bsp/barebox/barebox.inc
>> create mode 100644 meta/recipes-bsp/barebox/barebox_2014.07.0.bb
>>
>> diff --git a/meta/recipes-bsp/barebox/barebox.inc
>> b/meta/recipes-bsp/barebox/barebox.inc
>> new file mode 100644
>> index 000..68aeb68
>> --- /dev/null
>> +++ b/meta/recipes-bsp/barebox/barebox.inc
>> @@ -0,0 +1,73 @@
>> +SUMMARY = "The Barebox Bootloader"
>> +DESCRIPTION = "Barebox (formerly known as u-boot-v2) is a bootloader that
>> inherits the best of U-Boot and the Linux kernel: The size and look-and-feel
>> of u-boot, with driver model and lots of design concepts from the kernel."
>> +HOMEPAGE = "http://www.barebox.org";
>> +SECTION = "bootloaders"
>> +PROVIDES = "virtual/bootloader"
>> +
>> +inherit cml1 deploy kernel-arch
>> +
>> +EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc
>> ${TOOLCHAIN_OPTIONS}"'
>> +
>> +BAREBOX_BINARY ?= "barebox.bin"
>> +BAREBOX_IMAGE ?= "barebox-${MACHINE}-${PV}-${PR}.bin"
>> +BAREBOX_SYMLINK ?= "barebox-${MACHINE}.bin"
>> +
>> +do_configure () {
>> + # Copy defconfig to .config if .config does not exist. This allows
>> + # recipes to manage the .config themselves in do_configure_prepend().
>> + if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>> + cp "${WORKDIR}/defconfig" "${B}/.config"
>> + fi
>> +
>> + # Use board default defconfig if .config does not exist. This allows
>> + # recipes to manage the .config themselves in do_configure_prepend().
>> + if [ ! -f "${B}/.config" ]; then
>> + oe_runmake_call ${BAREBOX_TARGET}
>> + fi
>> +
>> + cml1_do_configure
>> +}
>> +
>> +do_compile () {
>> + if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold',
>> 'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
>> + sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g'
>> ${S}/Makefile
>> + fi
>> +
> I had to add that a few year ago : is that still needed ?
Don't know, I've taken that directly from u-boot recipe (didn't want
to reinvent the wheel)
>
>> + unset CFLAGS CPPFLAGS LDFLAGS
>> + oe_runmake
>> +}
>> +
>> +do_install () {
>> + install -d ${D}/boot
>> + install ${S}/barebox-flash-image ${D}/boot/${BAREBOX_IMAGE}
>> + ln -sf ${BAREBOX_IMAGE} ${D}/boot/${BAREBOX_BINARY}
>> +
>> + # Install target tools if available
>> + install -d ${D}${sbindir}
>> +
>> + if [ -e ${WORKDIR}/scripts/bareboxenv-target ]; then
>> + install -m 0755 ${WORKDIR}/scripts/bareboxenv-target
>> ${D}${sbindir}/bareboxenv
>> + fi
>> +
>> + if [ -e ${WORKDIR}/scripts/bareboxcrc32-target ]; then
>> + install -m 0755 ${WORKDIR}/scripts/bareboxcrc32-target
>> ${D}${sbindir}/bareboxcrc32
>> + fi
>> +
>> + if [ -e ${WORKDIR}/scripts/kernel-install-target ]; then
>> + install -m 0755 ${WORKDIR}/scripts/kernel-install-target
>> ${D}${sbindir}/kernel-install
>> + fi
>> +}
>> +
>> +FILES_${PN} = "/boot ${sbindir}"
>
> Why not splitting the tools in their own package so that we can have
> the tools on the target without having the binary in /boot ?
Create a barebox-tools recipe should also solve some problems I have
building the said tools (but it is more a question related to barebox
team than OE). I can do it if this request gets accepted. Could be a
v2 for this patch.
>
>> +
>> +do_deploy () {
>> + install -d ${DEPLOYDIR}
>> + install ${S}/barebox-flash-image ${DEPLOYDIR}/${BAREBOX_IMAGE}
>> +
> Why don't you use $BAREBOX_BINARY instead of hardcoding
> barebox-flash-image which won't work on old versions of barebox where
> barebox's binary is named barebox.bin ?
I didn't know that, but I am not sure I can use $BAREBOX_BINARY since
this variable is used in $DEPLOY_DIR. I tried to mimic u-boot recipe
behavior as much as possible.
>
> Best regards,
> Eric
Greetings,
David
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 1/1] systemd: upgrade to 215
Chen Qi writes: > The files under /usr/lib/sysusers.d/ are also added to CONFFILES. Are CONFFILES outside of /etc really allowed? Admin can override them in /etc/sysusers.d when he wants. Enrico -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] volatile-binds: add recipe
On 28 July 2014 06:34, Chen Qi wrote:
> +# This package is only for systemd based systems. So building it with
> 'systemd'
> +# missing in DISTRO_FEATURES makes no sense.
> +python () {
> +if not bb.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
> +raise bb.parse.SkipPackage("'systemd' not in DISTRO_FEATURES")
> +}
There's a class to help with this: distro_features_check.bbclass.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES
On Thu, 2014-07-24 at 17:22 +0200, Martin Jansa wrote: > On Thu, Jul 24, 2014 at 02:52:45PM +0100, Burton, Ross wrote: > > On 24 July 2014 14:42, Martin Jansa wrote: > > > +REQUIRED_DISTRO_FEATURES = "x11" > > > > Now I'm wondering why this is the solution. > > > > If you attempt to build e.g. gnome-desktop explicitly without the x11 > > distro feature you understandably get an error message, because > > gnome-desktop depends on libx11 which sanity checks the distro > > features. This seems correct. > > > > Presumably you're problem is that you're running world builds and > > they're producing errors on gnome-desktop because they can't satisfy a > > dependency on libx11. It seems that bubbling up the > > REQUIRED_DISTRO_FEATURES tests isn't the right thing to do here - why > > can't SkipPackage be handled specially, so if you do bitbake -k world > > and libx11 emits SkipPackage, anything that has unsatisfiable > > dependencies because of this is also skipped? > > We discussed this many months ago and IIRC the conclusion was that user > should explicitly say that he wants to skip the recipes which depend on > something skipped (so that he is aware of what he is missing). > > At that time there wasn't REQUIRED_DISTRO_FEATURES support, so I've > created huge list of PNBLACKLISTs to blacklist everything not available > in our setup - so I can do world builds without ERRORs at the beginning. > > REQUIRED_DISTRO_FEATURES seems to me like reasonable compromise, that's > why I've sent this patchset to replace small part of my huge blacklist. > > This is the list: > https://github.com/openwebos/meta-webos/blob/master/conf/distro/include/webos-recipe-blacklist-world.inc > > If someone has time to improve SkipPackage and we really want to skip > all depending packages, I would be glad to test such patch (because it > allows to easily drop all those blacklists for "depends-on-broken" > components) The question here is whether we want a system which calculates what it thinks is right or that we declare it. The risk is that if SkipPackage (now known as SkipRecipe) were to automatically "spread", you could in theory break the toolchain, have nothing buildable and "bitbake world" would return success. Effectively the -k option to bitbake already does the SkipPackage "spread" idea since bitbake just removes dependencies until it works. If does that in a fairly verbose way but it does so deliberately so you can see what is going on. The alternative is to declare what a given recipe supports and then we can know whether it should be skipped or not under a given circumstance. Personally, I'm leaning towards a more declarative approach where we specify what should and shouldn't be expected to work. I'm open to discussion on it though... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] systemd: add volatile-binds to RDEPENDS
On Mon, 2014-07-28 at 13:34 +0800, Chen Qi wrote:
> ---
> meta/recipes-core/systemd/systemd_213.bb |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/systemd/systemd_213.bb
> b/meta/recipes-core/systemd/systemd_213.bb
> index 5de7cdc..4fb7ffc 100644
> --- a/meta/recipes-core/systemd/systemd_213.bb
> +++ b/meta/recipes-core/systemd/systemd_213.bb
> @@ -243,6 +243,7 @@ FILES_${PN}-dbg += "${rootlibdir}/.debug
> ${systemd_unitdir}/.debug ${systemd_uni
> FILES_${PN}-dev += "${base_libdir}/security/*.la
> ${datadir}/dbus-1/interfaces/ ${sysconfdir}/rpm/macros.systemd"
>
> RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})"
> +RDEPENDS_${PN} += "volatile-binds"
>
> RRECOMMENDS_${PN} += "systemd-serialgetty systemd-compat-units udev-hwdb\
>util-linux-agetty \
Do we always need/want to include this? Does this have any implications
for rw systems? I couldn't immediately see how this triggers on a ro
system...
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OE Changelog since 2014-07-20 until 2014-07-27
Changelog since 2014-07-20 until 2014-07-27. 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 (7): toaster: add fields for sourcedir and builddir paths toaster: improved Project models toaster: move bldcontrol initial_data fixture to code toaster: add project main edit page toaster: properly set layers when running a build toaster-requirements.txt: document requirements for the python environment toasterui: fixing event.data clash Dennis Meier (1): fetch2: Add module for ClearCase (ccrc://) Richard Purdie (4): command/runqueue: Fix shutdown logic cache: Don't reload the cache file since we already have this data in memory cache: Optimise invalid cache file handling codeparser cache improvements Robert P. J. Day (7): bitbake-user-manual-intro.xml: Minor edits to start of intro chapter bitbake-user-manual-intro.xml: More edits to the intro chapter. bitbake-user-manual-execution.xml: Minor edits to execution chapter. bitbake-user-manual-metadata.xml: Adding some flag examples. bitbake-user-manual-metadata.xml: Added second conditional metadata example. bitbake-user-manual-metadata.xml: Removed fakeroot from list "per-package" should say "per-recipe" Robert Yang (3): bitbake-user-manual-metadata.xml: Replaced "populate_staging" bitbake: update help message for dump-signatures bitbake: remove choices for dump-signatures Scott Rifenbark (6): bitmake-user-manual-fetching.xml: Added transportuser parameter for SVN bitbake-user-manual-metadata.xml: Edits to some operators bitbake-user-manual-metadata.xml: Fixed whitespace bitbake-user-manual-metadata.xml: KERNEL_FEATURES example updated. bitbake-user-manual-metadata.xml: fixed some example whitespace issues Updated the the example 'bitbake -h' output to match the actual output, Changelog for openembedded-core: Alejandro del Castillo (1): util-linux: break out new package util-linux-hwclock Ben Shelton (2): busybox: mdev: Ensure /dev/initctl exists after tmpfs mount initscripts: fix bashism in bootmisc.sh Bill Pittman (1): busybox: mdev: Use mdev.seq Bruce Ashfield (8): linux-yocto/3.14: vexpress and MVM firmware support lttng-modules: update to 2.5.0 lttng-modules: re-enable ARM builds linux-yocto: x86_64: expand kernel stack to 16K linux-yocto-dev: bump to v3.16+ kernel: don't copy .so.dbg files into kernel source install linux-yocto/3.14: libata and generic CPU modalias handling kern-tools: adjust to full history meta-data Chen Qi (2): shadow: fix the behavior of su systemd: change dependency relationships Chong Lu (1): adt-installer: fix sed input file error Daniel BORNAZ (1): python: fix _
[OE-core] [PATCH] selftest/buildoptions.py: fix QA_WARN test and add more output when failing
The -ccleansstate should be done before building the package for the second
time.
Also printing the command output when failing.
Signed-off-by: Corneliu Stoicescu
---
meta/lib/oeqa/selftest/buildoptions.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/selftest/buildoptions.py
b/meta/lib/oeqa/selftest/buildoptions.py
index 27fc452..ec541e5 100644
--- a/meta/lib/oeqa/selftest/buildoptions.py
+++ b/meta/lib/oeqa/selftest/buildoptions.py
@@ -74,15 +74,15 @@ class SanityOptionsTest(oeSelfTest):
self.write_recipeinc('xcursor-transparent-theme', 'PACKAGES +=
\"${PN}-dbg\"')
res = bitbake("xcursor-transparent-theme", ignore_status=True)
self.delete_recipeinc('xcursor-transparent-theme')
-self.assertTrue("ERROR: QA Issue: xcursor-transparent-theme-dbg is
listed in PACKAGES multiple times, this leads to packaging errors." in
res.output)
+self.assertTrue("ERROR: QA Issue: xcursor-transparent-theme-dbg is
listed in PACKAGES multiple times, this leads to packaging errors." in
res.output, msg=res.output)
self.assertEqual(res.status, 1)
self.write_recipeinc('xcursor-transparent-theme', 'PACKAGES +=
\"${PN}-dbg\"')
self.append_config('ERROR_QA_remove = "packages-list"')
self.append_config('WARN_QA_append = " packages-list"')
-res = bitbake("xcursor-transparent-theme")
bitbake("xcursor-transparent-theme -ccleansstate")
+res = bitbake("xcursor-transparent-theme")
self.delete_recipeinc('xcursor-transparent-theme')
-self.assertTrue("WARNING: QA Issue: xcursor-transparent-theme-dbg is
listed in PACKAGES multiple times, this leads to packaging errors." in
res.output)
+self.assertTrue("WARNING: QA Issue: xcursor-transparent-theme-dbg is
listed in PACKAGES multiple times, this leads to packaging errors." in
res.output, msg=res.output)
def test_sanity_userspace_dependency(self):
self.append_config('WARN_QA_append = " unsafe-references-in-binaries
unsafe-references-in-scripts"')
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] alsa-lib: Add RPROVIDES for alsa-dev
From: Jackie Huang
previous commit removes non PN based -dev packages
but lack of upgrade path for alsa-dev, add RPROVIDES
for this.
Signed-off-by: Jackie Huang
---
meta/recipes-multimedia/alsa/alsa-lib_1.0.27.2.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.0.27.2.bb
b/meta/recipes-multimedia/alsa/alsa-lib_1.0.27.2.bb
index 9132072..996d78b 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.0.27.2.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.0.27.2.bb
@@ -46,3 +46,4 @@ ${datadir}/alsa/pcm/dmix.conf \
${datadir}/alsa/pcm/dsnoop.conf"
RDEPENDS_libasound = "alsa-conf-base"
+RPROVIDES_${PN}-dev = "alsa-dev"
--
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] alsa-lib: Add RPROVIDES for alsa-dev
On 28 July 2014 15:19, wrote:
> +RPROVIDES_${PN}-dev = "alsa-dev"
I believe you'll want replaces and conflicts too, so that alsa-dev gets removed.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] libpcap-ng
On 7/25/14, 10:02 PM, Khem Raj wrote: On Fri, Jul 25, 2014 at 3:45 PM, akuster wrote: Meta-security and Meta-selinux both have libcap-ng. Instead of maintaining the same package in both places, can we get it into OE where libcap resides? I think at very least you can propose it for meta-oe if not or-core. But I also wonder why meta-selinux is not a sub-layer under meta-security, meta-selinux existed first... no other reason. The last time I looked at meta-security (well over a year ago), it wasn't terribly useful. It was just a random collection of security-like packages, some worked, some didn't. If it has grown since then to be more of a cohesive set of packages, then meta-selinux being part of it may make sense. --Mark -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] barebox: Add recipe
Hi David, Le Mon, 28 Jul 2014 14:15:12 +0200, David Vincent a écrit : > > Why don't you use $BAREBOX_BINARY instead of hardcoding > > barebox-flash-image which won't work on old versions of barebox where > > barebox's binary is named barebox.bin ? > > I didn't know that, but I am not sure I can use $BAREBOX_BINARY since > this variable is used in $DEPLOY_DIR. I tried to mimic u-boot recipe > behavior as much as possible. > you can use the variable as it's defined upper. u-boot recipe does it this way : http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot.inc#n19 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot.inc#n63 FWIW you can find here the initial barebox recipe we have in meta-fsl-arm : https://github.com/Freescale/meta-fsl-arm/tree/master/recipes-bsp/barebox Best regards, Eric -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk_base: Fix grep command usage on old hosts
"man grep" on centos:
-R, -r, --recursive
Read all files under each directory, recursively; this is
equivalent to the -d recurse option.
"man grep" on a more recent ubuntu system:
-r, --recursive
Read all files under each directory, recursively, following
symbolic links only if they are on the command line. This
is equivalent to the -d recurse option.
So we have an issue when the SDK installer (even with
buildtools-tarball) is used on old hosts since it may try and
dereference paths which it should not. This is caused by differences in
the behaviour of grep -r on older systems.
The fix is to wrap this in find so that only real files are found (as
elsewhere in the script.
[YOCTO #6577]
Signed-off-by: Richard Purdie
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index 893afbb..06112dc 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -285,7 +285,7 @@ done
# find out all perl scripts in $native_sysroot and modify them replacing the
# host perl with SDK perl.
-for perl_script in $($SUDO_EXEC grep "^#!.*perl" -rl $native_sysroot); do
+for perl_script in $($SUDO_EXEC find $native_sysroot -type f -exec grep
"^#!.*perl" -l '{}' \;); do
$SUDO_EXEC sed -i -e "s:^#! */usr/bin/perl.*:#! /usr/bin/env perl:g" -e
\
"s: /usr/bin/perl: /usr/bin/env perl:g" $perl_script
done
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] SELinux support
[ https://bugzilla.yoctoproject.org/show_bug.cgi?id=6580 ] Hi, after upgrade to recent pseudo 1.6+, oe-core stops to build as a confined SELinux now. This happens because SELinux provides more than the xattr file api and 'pseudo' does not intercept e.g. writing into '/proc/self/attr/fscreate'. IMO, turning off every SELinux related operation in do_install() (which is wrapped by 'pseudo') is a clean way to fix and improve building. If OE supports SELinux for targets sometime, the file relabeling should be done in do_rootfs() by using a chroot aware 'restorecon' (e.g. which reads the file context policy from the chroot but not from system wide /etc/selinux). Unfortunately, I do not know a way to make applications think they are running without SELinux. But patching 'pseudo' to return faked values for 'is_selinux_enabled()' seems to be a good solution. Bug #6580 mentioned at the beginning contains some discussion and a patch. What do other people think about it? Enrico -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gmp: redefine a function
On Mon, Jul 28, 2014 at 4:01 AM, wrote: > +[PATCH] reimplement umul_ppmm to make it be able to building on mips64 64bit > ABI > + > +Upstream-Status: Pending[This version was not maintained by upstream, larger > versions have been fixed] > + if you mean newer release have been fixed then this patch should be marked 'Backport' -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] gcc-cross-canadian: Adjust $prefix to fix sysroot autodetect
Bump?
Richard Tollerton writes:
> Currently, using gcc-cross-canadian often requires --sysroot to be
> specified at compile time, because the default sysroot is hardcoded to
> e.g. /opt/poky/1.6.1/sysroots/core2-64-poky-linux. If you didn't install
> the toolchain in precisely that location, the default sysroot won't work.
>
> But that isn't actually necessary -- gcc is actually capable of
> discovering the sysroot location itself. If the default
> sysroot (--with-sysroot=) is underneath the prefix (--prefix=), then gcc
> rewrites the sysroot at runtime based on the actual location of gcc in
> the filesystem. (cf gcc/gcc.c:process_command() in the
> defined(TARGET_SYSTEM_ROOT_RELOCATABLE), and
> libiberty/make-relative-prefix.c, in the gcc sources.)
>
> We can effect this by moving prefix up a few directories.
> Currently it's effectively set to ${SDKPATH}/sysroots/${SDK_SYS}/usr,
> via nativesdk.bbclass. So instead, set it to ${SDKPATH}/sysroots.
> This breaks nothing, because autotools.bbclass already sets
> exec_prefix, bindir, etc. so that this change should not actually affect
> where files get installed.
>
> Natinst-ReviewBoard-ID: 52189
> Acked-by: Gratian Crisan
> Acked-by: David Curtiss
> Signed-off-by: Richard Tollerton
> ---
> meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> index 63adae8..1a826ec 100644
> --- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> @@ -37,6 +37,9 @@ export RANLIB_FOR_TARGET = "${TARGET_PREFIX}ranlib"
> export STRIP_FOR_TARGET = "${TARGET_PREFIX}strip"
> export WINDRES_FOR_TARGET = "${TARGET_PREFIX}windres"
>
> +# Ensure that the target sysroot is under the prefix
> +prefix = "${SDKPATH}/sysroots"
> +
> #
> # We need to override this and make sure the compiler can find staging
> #
> --
> 2.0.1
>
--
Richard Tollerton
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] PSEUDO - SELinux support
On 7/28/14, 12:01 PM, Enrico Scholz wrote: [ https://bugzilla.yoctoproject.org/show_bug.cgi?id=6580 ] Hi, after upgrade to recent pseudo 1.6+, oe-core stops to build as a confined SELinux now. This happens because SELinux provides more than the xattr file api and 'pseudo' does not intercept e.g. writing into '/proc/self/attr/fscreate'. The issue is that there are two ways to set the selinux values. One is via xattr, which we do capture in pseudo -- specifically to allow components to set xattrs [including security attributes]. The other is via some random proc file entry. This was previously unknown to me. There is a slight chance we can attempt to capture access to that file as well and act on it within the pseudo context. (This may be more difficult though.) IMO, turning off every SELinux related operation in do_install() (which is wrapped by 'pseudo') is a clean way to fix and improve building. If OE supports SELinux for targets sometime, the file relabeling should be done in do_rootfs() by using a chroot aware 'restorecon' (e.g. which reads the file context policy from the chroot but not from system wide /etc/selinux). My feeling is that the security contexts set when pseudo is running should never make it to the 'real' filesystem, and should only be stored internally. If we have programs that are setting security contexts on the system, as a host-tool -- this will end up being host-contamination as well. As for the restorecon, there are otherways of setting security contexts as well. Look at the 'Tizen' smack stuff as an example. During the package installs they run through a series of rpm(4) plugins that evaluate what was installed and assign an appropriate security context. While these are not selinux contexts, the interface is similar. Unfortunately, I do not know a way to make applications think they are running without SELinux. But patching 'pseudo' to return faked values for 'is_selinux_enabled()' seems to be a good solution. This could work, but I think it's only part of the solution. We need to tell applications to stop spewing contexts that have nothing to do with the (virtual) filesystem we're working with. We also need to get a reasonable way to make sure pseudo is capturing all of the contexts it can. My other concern with the is_selinux_enabled is that it's not an API within the libc functions. So would defining this cause any issues? I'm not sure either way. At a minimum, telling a pseudo running session that selinux is not enabled (at the host level) is probably the correct behavior. Intercepting xattr is needed, and potentially access to the special proc files may also be needed... [once we intercept though, what do we do with the data?] Bug #6580 mentioned at the beginning contains some discussion and a patch. What do other people think about it? We definitely need input on this for people's use cases so that we can come up with a reasonable solution. As mentioned in the bug, pseudo was not originally designed to work in any type of selinux enforcing mode. If it happened to work, great -- but we didn't do any engineering there. We knew that some levels of selinux support and grsec support would cause pseudo to not be able to LD_PRELOAD, which would fail. The recommendation has always been to put your build machines behind a firewall, and put selinux into permissive mode (or disable it). But if we can try to make the level of accidental functionality continue to work, I'm all for it. --Mark -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] packagegroup-core-standalone-sdk-target: include static libs
From: Richard Tollerton
meta-toolchain ought to include static libs. This fixes an issue we saw
where a compile against libsupc++.a failed due to the missing library.
Acked-by: Gratian Crisan
Acked-by: Brad Mouring
Acked-by: Ken Sharp
Signed-off-by: Richard Tollerton
Signed-off-by: Ben Shelton
---
.../packagegroups/packagegroup-core-standalone-sdk-target.bb | 1 +
1 file changed, 1 insertion(+)
diff --git
a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
index 5d1ce97..da57b36 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
@@ -9,6 +9,7 @@ RDEPENDS_${PN} = "\
libgcc-dev \
libstdc++ \
libstdc++-dev \
+libstdc++-staticdev \
${LIBC_DEPENDENCIES} \
qemuwrapper-cross \
"
--
2.0.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] add USE_LDCONFIG_CONF_D
It'd be nice to support ld.so.conf.d, but it'd also be nice if it were optional. I made the default be zero because I don't want to change behavior on people without warning. Lightly tested, but since I don't actually have a use case for this lying around I can't promise it solves all the things. The main intended benefit is that packages can install files in ld.so.conf without stepping on each other. The following changes since commit 91ca6b1b2e009381d8e813906654c0958eee7efc: lib/oe/rootfs: Improve error message whitespace (2014-07-28 12:20:56 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib seebs/ldsoconfd http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/ldsoconfd Peter Seebach (1): Add support for ld.so.conf.d meta/recipes-core/eglibc/eglibc-package.inc | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] Add support for ld.so.conf.d
The default behavior for USE_LDCONFIG is to use an empty ld.so.conf.
In some cases, it might be desireable to have an ld.so.conf.d directory,
and inherit files from there. This is a common enough use case to
justify support in the recipe, but not common enough to make it the
default. So, eglibc gets a new USE_LDCONFIG_CONF_D value, default 0.
If it's set to 1, we create the directory and add an "include" line
for it to ld.so.conf.
Signed-off-by: Peter Seebach
---
meta/recipes-core/eglibc/eglibc-package.inc | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index c357a13..8026199 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -16,6 +16,9 @@ python __anonymous () {
# Set this to zero if you don't want ldconfig in the output package
USE_LDCONFIG ?= "1"
+# Set this to one if you want ld.so.conf to include ld.so.conf.d/*
+# by default.
+USE_LDCONFIG_CONF_D ?= "0"
PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile
libsotruss ${PN} eglibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
@@ -33,7 +36,7 @@ RPROVIDES_${PN}-pcprofile = "glibc-pcprofile"
RPROVIDES_${PN}-dbg = "glibc-dbg"
libc_baselibs = "${base_libdir}/libcrypt*.so.* ${base_libdir}/libcrypt-*.so
${base_libdir}/libc.so.* ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.*
${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so
${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so
${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so
${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so
${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so
${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so
${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so
${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so
${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so
${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so
${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so
${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
-FILES_${PN} = "${libc_baselibs} ${libexecdir}/*
${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
${sysconfdir}/ld.so.conf', '', d)}"
+FILES_${PN} = "${libc_baselibs} ${libexecdir}/*
${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
${sysconfdir}/ld.so.conf ${sysconfdir}/ld.so.conf.d', '', d)}"
FILES_ldd = "${bindir}/ldd"
FILES_libsegfault = "${base_libdir}/libSegFault*"
FILES_libcidn = "${base_libdir}/libcidn-*.so ${base_libdir}/libcidn.so.*"
@@ -99,6 +102,11 @@ do_install_append () {
if [ -d ${D}${sysconfdir} ]; then
rmdir ${D}${sysconfdir}
fi
+ else
+ if [ "${USE_LDCONFIG_CONF_D}" = "1" ]; then
+ mkdir -p ${D}${sysconfdir}/ld.so.conf.d
+ echo "include ld.so.conf.d/*.conf" >>
${D}${sysconfdir}/ld.so.conf
+ fi
fi
}
--
1.7.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] packagegroup-core-standalone-sdk-target: include static libs
On Mon, Jul 28, 2014 at 11:26 AM, Ben Shelton wrote: > meta-toolchain ought to include static libs. This fixes an issue we saw > where a compile against libsupc++.a failed due to the missing library. I don't think this is a good idea. There are license implications of static linking. You have to specific about it. However this case is different since libsupc++ is special library and also have runtime exceptions. You should move this library to libstdc++-dev package instead. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] Add support for ld.so.conf.d
On Mon, Jul 28, 2014 at 11:39 AM, Peter Seebach wrote: > The default behavior for USE_LDCONFIG is to use an empty ld.so.conf. > In some cases, it might be desireable to have an ld.so.conf.d directory, > and inherit files from there. This is a common enough use case to > justify support in the recipe, but not common enough to make it the > default. So, eglibc gets a new USE_LDCONFIG_CONF_D value, default 0. > If it's set to 1, we create the directory and add an "include" line > for it to ld.so.conf. the patch is good but introducing another variable is not needed you can cover it under US_LDCONFIG itself, ldconfig with empty ld.so.conf will still parse standard lib search paths anyway Secondly when we use ldconfig it generates ld.so.cache under /etc so I hope we take care of this when we have ro-rootfs -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] Add support for ld.so.conf.d
On 7/28/14, 1:47 PM, Khem Raj wrote: On Mon, Jul 28, 2014 at 11:39 AM, Peter Seebach wrote: The default behavior for USE_LDCONFIG is to use an empty ld.so.conf. In some cases, it might be desireable to have an ld.so.conf.d directory, and inherit files from there. This is a common enough use case to justify support in the recipe, but not common enough to make it the default. So, eglibc gets a new USE_LDCONFIG_CONF_D value, default 0. If it's set to 1, we create the directory and add an "include" line for it to ld.so.conf. the patch is good but introducing another variable is not needed you can cover it under US_LDCONFIG itself, ldconfig with empty ld.so.conf will still parse standard lib search paths anyway Secondly when we use ldconfig it generates ld.so.cache under /etc so I hope we take care of this when we have ro-rootfs In a read-only root case, the ld.so.cache is generated in the cross environment. I don't know if the cross ldconfig knows about the includes though. Someone will have to check that. --Mark -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] Add support for ld.so.conf.d
On Mon, 28 Jul 2014 11:47:30 -0700 Khem Raj wrote: > the patch is good but introducing another variable is not needed you > can cover it under US_LDCONFIG itself, ldconfig with empty ld.so.conf > will still parse standard lib search paths anyway The reason I wanted another variable is to control the creation of a *non-empty* ld.so.conf that would pick up other config files. The idea is that if you wanted to add a non-standard library search path, you could create a file in ld.so.conf.d. I didn't want to make the file have contents unconditionally. > Secondly when we use ldconfig it generates ld.so.cache under /etc > so I hope we take care of this when we have ro-rootfs I assume that's already working for the existing empty ld.so.conf you get with USE_LDCONFIG=1. It does occur to me that I don't know whether our cross-ldconfig knows this syntax. I'll double-check that. -s -- Listen, get this. Nobody with a good compiler needs to be justified. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] Add support for ld.so.conf.d
On Mon, 28 Jul 2014 13:59:20 -0500 Mark Hatle wrote: > In a read-only root case, the ld.so.cache is generated in the cross > environment. > I don't know if the cross ldconfig knows about the includes though. > Someone > will have to check that. It appears to be the same source, so it has the functionality at least in the code. -s -- Listen, get this. Nobody with a good compiler needs to be justified. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] libpcap-ng
On 07/28/2014 07:33 AM, Mark Hatle wrote: On 7/25/14, 10:02 PM, Khem Raj wrote: On Fri, Jul 25, 2014 at 3:45 PM, akuster wrote: Meta-security and Meta-selinux both have libcap-ng. Instead of maintaining the same package in both places, can we get it into OE where libcap resides? I think at very least you can propose it for meta-oe if not or-core. I think core libcap-ng recipe belongs in a common layer and not maintained in two places. But I also wonder why meta-selinux is not a sub-layer under meta-security, meta-selinux existed first... no other reason. The last time I looked at meta-security (well over a year ago), it wasn't terribly useful. Well when a security package like 'snort' and maybe others are in other locations, I can see why meta-security won't be very useful. It was just a random collection of security-like packages, some worked, some didn't. Hopefully that will change. - Armin If it has grown since then to be more of a cohesive set of packages, then meta-selinux being part of it may make sense. --Mark -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gmp: redefine a function
On 07/29/2014 01:25 AM, Khem Raj wrote: On Mon, Jul 28, 2014 at 4:01 AM, wrote: +[PATCH] reimplement umul_ppmm to make it be able to building on mips64 64bit ABI + +Upstream-Status: Pending[This version was not maintained by upstream, larger versions have been fixed] + if you mean newer release have been fixed then this patch should be marked 'Backport' newer releases are GPLv3, we can not backport patch from them -R -- Best Reagrds, Roy | RongQing Li -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] libpcap-ng
On Mon, Jul 28, 2014 at 5:28 PM, akuster wrote: >>> >>> I think at very least you can propose it for meta-oe if not or-core. > > > I think core libcap-ng recipe belongs in a common layer and not maintained > in two places. yes meta-oe is kind of extended common layer besides oe-core, if it can be proven that we can drop libpcap and replace its use completely with libpcap-ng you might have a better case to include it in oe-core, > > >>> But I also wonder why meta-selinux is not a sub-layer under >>> meta-security, >>> >> >> meta-selinux existed first... no other reason. >> >> >> The last time I looked at meta-security (well over a year ago), it >> wasn't terribly useful. > > > Well when a security package like 'snort' and maybe others are in other > locations, I can see why meta-security won't be very useful. > > > It was just a random collection of >> >> security-like packages, some worked, some didn't. > > > Hopefully that will change. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gmp: redefine a function
On Mon, Jul 28, 2014 at 5:36 PM, Rongqing Li wrote: > > > On 07/29/2014 01:25 AM, Khem Raj wrote: >> >> On Mon, Jul 28, 2014 at 4:01 AM, wrote: >>> >>> +[PATCH] reimplement umul_ppmm to make it be able to building on mips64 >>> 64bit ABI >>> + >>> +Upstream-Status: Pending[This version was not maintained by upstream, >>> larger versions have been fixed] >>> + >> >> >> if you mean newer release have been fixed then this patch should be >> marked 'Backport' >> > > > newer releases are GPLv3, we can not backport patch from them I see. So you did a clean room implementation then ? if not then you could request the original patch author to release it under GPLv2 license for back portability > > -R > >> > > -- > Best Reagrds, > Roy | RongQing Li -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gmp: redefine a function
On 07/29/2014 08:43 AM, Khem Raj wrote: On Mon, Jul 28, 2014 at 5:36 PM, Rongqing Li wrote: On 07/29/2014 01:25 AM, Khem Raj wrote: On Mon, Jul 28, 2014 at 4:01 AM, wrote: +[PATCH] reimplement umul_ppmm to make it be able to building on mips64 64bit ABI + +Upstream-Status: Pending[This version was not maintained by upstream, larger versions have been fixed] + if you mean newer release have been fixed then this patch should be marked 'Backport' newer releases are GPLv3, we can not backport patch from them I see. So you did a clean room implementation then ? if not then you could request the original patch author to release it under GPLv2 license for back portability Ok, I will ask; But If the author do not like to release it under GPLv2, what should I do? -Roy -R -- Best Reagrds, Roy | RongQing Li -- Best Reagrds, Roy | RongQing Li -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gmp: redefine a function
On Mon, Jul 28, 2014 at 5:53 PM, Rongqing Li wrote: > But If the author do not like to release it under GPLv2, what should I do? it has to then be a clean room implementation. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] backport patches for gmp-4.x.x
Torbjorn Granlund:
we am using the gmp-4.2.1, but compiling gmp failed on mips64
and 64bit userspace, I see the patch 12418[(mips, powerpc):
Provide assembly-free umul_ppmm for newer gcc] can fix it. but
it is under GPLv3;
Could you release this patch under GPLv2?
Thanks
-Roy
# HG changeset patch
# User Torbjorn Granlund
# Date 1235947651 -3600
# Node ID 12a1d0bf21f09b05813edd5e19496ae65544cfab
# Parent 6411165312970e38a469d0236eff67ecc372223e
(mips, powerpc): Provide assembly-free umul_ppmm for newer gcc.
diff -r 641116531297 -r 12a1d0bf21f0 longlong.h
--- a/longlong.h Wed Feb 04 11:32:34 2009 +0100
+++ b/longlong.h Sun Mar 01 23:47:31 2009 +0100
@@ -1,7 +1,7 @@
/* longlong.h -- definitions for mixed size 32/64 bit arithmetic.
Copyright 1991, 1992, 1993, 1994, 1996, 1997, 1999, 2000, 2001, 2002, 2003,
-2004, 2005, 2007 Free Software Foundation, Inc.
+2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
This file is free software; you can redistribute it and/or modify it under the
terms of the GNU Lesser General Public License as published by the Free
@@ -1021,10 +1021,19 @@
#endif /* __m88000__ */
#if defined (__mips) && W_TYPE_SIZE == 32
-#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+UDItype __ll = (UDItype)(u) * (v); \
+w1 = __ll >> 32; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm) && __GMP_GNUC_PREREQ (2,7)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
-#else
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("multu %2,%3\n\tmflo %0\n\tmfhi %1"\
: "=d" (w0), "=d" (w1) : "d" (u), "d" (v))
@@ -1034,10 +1043,20 @@
#endif /* __mips */
#if (defined (__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
+__ll_UTItype __ll = (__ll_UTItype)(u) * (v); \
+w1 = __ll >> 64; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm) && __GMP_GNUC_PREREQ (2,7)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("dmultu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
-#else
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("dmultu %2,%3\n\tmflo %0\n\tmfhi %1"\
: "=d" (w0), "=d" (w1) : "d" (u), "d" (v))
@@ -1140,12 +1159,22 @@
__asm__ ("{cntlz|cntlzw} %0,%1" : "=r" (count) : "r" (x))
#define COUNT_LEADING_ZEROS_0 32
#if HAVE_HOST_CPU_FAMILY_powerpc
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+UDItype __ll = (UDItype)(u) * (v); \
+w1 = __ll >> 32; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(ph, pl, m0, m1) \
do { \
USItype __m0 = (m0), __m1 = (m1); \
__asm__ ("mulhwu %0,%1,%2" : "=r" (ph) : "%r" (m0), "r" (m1)); \
(pl) = __m0 * __m1; \
} while (0)
+#endif
#define UMUL_TIME 15
#define smul_ppmm(ph, pl, m0, m1) \
do { \
@@ -1229,12 +1258,23 @@
#define count_leading_zeros(count, x) \
__asm__ ("cntlzd %0,%1" : "=r" (count) : "r" (x))
#define COUNT_LEADING_ZEROS_0 64
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
+__ll_UTItype __ll = (__ll_UTItype)(u) * (v); \
+w1 = __ll >> 64; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(ph, pl, m0, m1) \
do { \
UDItype __m0 = (m0), __m1 = (m1); \
__asm__ ("mulhdu %0,%1,%2" : "=r" (ph) : "%r" (m0), "r" (m1)); \
(pl) = __m0 * __m1; \
} while (0)
+#endif
#define UMUL_TIME 15
#define smul_ppmm(ph, pl, m0, m1) \
do { \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] gcc-4.9.inc: fix parallel building failure
On 07/25/2014 11:48 PM, Saul Wold wrote:
Can you please rebase this against master as we have already merged
the first version.
No problem, I am working on it
//Hongxu
Thanks
Sau!
On 07/25/2014 03:13 AM, Hongxu Jia wrote:
The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included
config.h which was a generated file. But no explicity rule
to clarify the dependency. There was potential building
failure while parallel make.
For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C
source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the
'$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these
objects.
For errors.o, it is part of gengtype, and the gengtype generator program
is special: Two versions are built. One is for the build machine, and
one
is for the host. We refered what gengtype-parse.o did (which also is
part
of gengtype).
[YOCTO #6568]
Signed-off-by: Hongxu Jia
---
meta/recipes-devtools/gcc/gcc-4.9.inc | 1 +
...Makefile.in-fix-parallel-building-failure.patch | 64
++
2 files changed, 65 insertions(+)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index cbf1355..10bd5d5 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -67,6 +67,7 @@ SRC_URI =
"${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
file://0051-eabispe.patch \
file://0052-Fix-GCC-targeting-E500-SPE-errors-with-the-_Decimal64-type.patch
\
file://0053-gcc-fix-segfault-from-calling-free-on-non-malloc-d-a.patch \
+ file://0054-gcc-Makefile.in-fix-parallel-building-failure.patch \
"
SRC_URI[md5sum] = "9709b49ae0e904cbb0a6a1b62853b556"
SRC_URI[sha256sum] =
"b9b047a97bade9c1c89970bc8e211ff57b7b8998a1730a80a653d329f8ed1257"
diff --git
a/meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch
b/meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch
new file mode 100644
index 000..6277bec
--- /dev/null
+++
b/meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch
@@ -0,0 +1,64 @@
+From 5a50cebd00930930e609e978331ede690f34512b Mon Sep 17 00:00:00 2001
+From: Hongxu Jia
+Date: Fri, 25 Jul 2014 14:35:17 +0800
+Subject: [PATCH] gcc/Makefile.in: fix parallel building failure
+
+The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included
+config.h which was a generated file. But no explicity rule
+to clarify the dependency. There was potential building
+failure while parallel make.
+
+For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C
+source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the
+'$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these
+objects.
+
+For errors.o, it is part of gengtype, and the gengtype generator
program
+is special: Two versions are built. One is for the build machine,
and one
+is for the host. We refered what gengtype-parse.o did (which also is
part
+of gengtype).
+
+[GCC #61899]
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61899
+
+Upstream-Status: Send to gcc-patc...@gcc.gnu.org mailing list
+
+Signed-off-by: Hongxu Jia
+---
+ gcc/Makefile.in | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/gcc/Makefile.in b/gcc/Makefile.in
+index 6475cba..56e50bb 100644
+--- a/gcc/Makefile.in
b/gcc/Makefile.in
+@@ -1481,13 +1481,16 @@ OBJS-libcommon-target =
$(common_out_object_file) prefix.o params.o \
+ opts.o opts-common.o options.o vec.o hooks.o
common/common-targhooks.o \
+ hash-table.o file-find.o
+
++# Objects compiled from one C source file gcc-ar.c
++OBJS-gcc-ar = gcc-ar.o gcc-nm.o gcc-ranlib.o
++
+ # This lists all host objects for the front ends.
+ ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
+
+ ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \
+ $(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \
+ $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \
+- lto-wrapper.o
++ lto-wrapper.o $(OBJS-gcc-ar)
+
+ # This lists all host object files, whether they are included in this
+ # compilation or not.
+@@ -2437,6 +2440,8 @@ gengtype-parse.o: $(CONFIG_H)
+ CFLAGS-build/gengtype-parse.o += -DGENERATOR_FILE
+ build/gengtype-parse.o: $(BCONFIG_H)
+
++errors.o : $(CONFIG_H)
++
+ gengtype-state.o build/gengtype-state.o: gengtype-state.c
$(SYSTEM_H) \
+ gengtype.h errors.h double-int.h version.h $(HASHTAB_H)
$(OBSTACK_H) \
+ $(XREGEX_H)
+--
+1.8.1.2
+
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] backport patches for gmp-4.x.x
Torbjorn Granlund:
we are using the gmp-4.2.1, but compiling gmp failed on mips64
and 64bit userspace, I see the patch 12418[(mips, powerpc):
Provide assembly-free umul_ppmm for newer gcc] can fix it. but
it is under GPLv3;
Could you release this patch under GPLv2?
Thanks
-Roy
# HG changeset patch
# User Torbjorn Granlund
# Date 1235947651 -3600
# Node ID 12a1d0bf21f09b05813edd5e19496ae65544cfab
# Parent 6411165312970e38a469d0236eff67ecc372223e
(mips, powerpc): Provide assembly-free umul_ppmm for newer gcc.
diff -r 641116531297 -r 12a1d0bf21f0 longlong.h
--- a/longlong.h Wed Feb 04 11:32:34 2009 +0100
+++ b/longlong.h Sun Mar 01 23:47:31 2009 +0100
@@ -1,7 +1,7 @@
/* longlong.h -- definitions for mixed size 32/64 bit arithmetic.
Copyright 1991, 1992, 1993, 1994, 1996, 1997, 1999, 2000, 2001, 2002, 2003,
-2004, 2005, 2007 Free Software Foundation, Inc.
+2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
This file is free software; you can redistribute it and/or modify it under the
terms of the GNU Lesser General Public License as published by the Free
@@ -1021,10 +1021,19 @@
#endif /* __m88000__ */
#if defined (__mips) && W_TYPE_SIZE == 32
-#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+UDItype __ll = (UDItype)(u) * (v); \
+w1 = __ll >> 32; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm) && __GMP_GNUC_PREREQ (2,7)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
-#else
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("multu %2,%3\n\tmflo %0\n\tmfhi %1"\
: "=d" (w0), "=d" (w1) : "d" (u), "d" (v))
@@ -1034,10 +1043,20 @@
#endif /* __mips */
#if (defined (__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
+__ll_UTItype __ll = (__ll_UTItype)(u) * (v); \
+w1 = __ll >> 64; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm) && __GMP_GNUC_PREREQ (2,7)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("dmultu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
-#else
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(w1, w0, u, v) \
__asm__ ("dmultu %2,%3\n\tmflo %0\n\tmfhi %1"\
: "=d" (w0), "=d" (w1) : "d" (u), "d" (v))
@@ -1140,12 +1159,22 @@
__asm__ ("{cntlz|cntlzw} %0,%1" : "=r" (count) : "r" (x))
#define COUNT_LEADING_ZEROS_0 32
#if HAVE_HOST_CPU_FAMILY_powerpc
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+UDItype __ll = (UDItype)(u) * (v); \
+w1 = __ll >> 32; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(ph, pl, m0, m1) \
do { \
USItype __m0 = (m0), __m1 = (m1); \
__asm__ ("mulhwu %0,%1,%2" : "=r" (ph) : "%r" (m0), "r" (m1)); \
(pl) = __m0 * __m1; \
} while (0)
+#endif
#define UMUL_TIME 15
#define smul_ppmm(ph, pl, m0, m1) \
do { \
@@ -1229,12 +1258,23 @@
#define count_leading_zeros(count, x) \
__asm__ ("cntlzd %0,%1" : "=r" (count) : "r" (x))
#define COUNT_LEADING_ZEROS_0 64
+#if __GMP_GNUC_PREREQ (4,4)
+#define umul_ppmm(w1, w0, u, v) \
+ do { \
+typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
+__ll_UTItype __ll = (__ll_UTItype)(u) * (v); \
+w1 = __ll >> 64; \
+w0 = __ll;\
+ } while (0)
+#endif
+#if !defined (umul_ppmm)
#define umul_ppmm(ph, pl, m0, m1) \
do { \
UDItype __m0 = (m0), __m1 = (m1); \
__asm__ ("mulhdu %0,%1,%2" : "=r" (ph) : "%r" (m0), "r" (m1)); \
(pl) = __m0 * __m1; \
} while (0)
+#endif
#define UMUL_TIME 15
#define smul_ppmm(ph, pl, m0, m1) \
do { \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] [PATCH v2][meta-perl] libxml-sax-writer-perl: add recipe
On 07/25/2014 01:10 PM, Rongqing Li wrote:
On 07/24/2014 07:14 PM, Martin Jansa wrote:
On Tue, Jul 22, 2014 at 03:06:53PM +0800, rongqing...@windriver.com
wrote:
From: Roy Li
Sorry, but it still isn't correct even with allarch, because there is
dependency on TUNE_PKGARCH perl:
ERROR: libxml-filter-buffertext-perl different signature for task
do_configure.sigdata between qemux86copy and qemuarm
Hash for dependent task perl_5.20.0.bb.do_populate_sysroot changed
from a5827c8deafb0ace555794c62c44e19f to 1a07f7ac7ad2a2750b58dfa60136114b
ERROR: libxml-sax-writer-perl different signature for task
do_configure.sigdata between qemux86copy and qemuarm
Hash for dependent task perl_5.20.0.bb.do_populate_sysroot changed
from a5827c8deafb0ace555794c62c44e19f to 1a07f7ac7ad2a2750b58dfa60136114b
1. I can not reproduce it, where are my steps be wrong?
$ ../scripts/sstate-diff-machines.sh --tmpdir=tmp/ --machines="qemuarm
qemux86copy qemux86-64" --targets=libxml-sax
-writer-perl
...
NOTE: Preparing runqueue
NOTE: Reparsing files to collect dependency data
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be
rerun and all succeeded.
INFO: Output written in:
/buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562
$cd /buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562
$
builder@pek-yocto-build1:/buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562$
find . |grep writer-perl|grep sysroot
./qemux86copy/all-poky-linux/libxml-sax-writer-perl/0.54-r0.do_populate_sysroot.sigdata.323a1635a2b08060e64815de8e009281
./qemuarm/all-poky-linux/libxml-sax-writer-perl/0.54-r0.do_populate_sysroot.sigdata.323a1635a2b08060e64815de8e009281
./qemux86-64/all-poky-linux/libxml-sax-writer-perl/0.54-r0.do_populate_sysroot.sigdata.323a1635a2b08060e64815de8e009281
builder@pek-yocto-build1:/buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562$
2. the cause maybe the below:
perl module will depend on perl, but perl is not allarch, so make your
error.
meta/classes/cpan-base.bbclass
7 DEPENDS += "${@["perl",
"perl-native"][(bb.data.inherits_class('native', d))]}"
8 RDEPENDS_${PN} += "${@["perl",
""][(bb.data.inherits_class('native', d))]}"
3. no perl modules inherit allarch in oe-core;
oe-core$ find ./ -name "*perl*bb" -exec grep allarch {} \;
oe-core$
but I think some module should be allarch, like: libxml-simple-perl
https://packages.debian.org/search?keywords=libxml-simple-perl&searchon=names&suite=stable§ion=all
Martin Jansa:
What should I do? make this recipes not to inherit allarch?
or remove the adding dependency on perl from cpan-base.bbclass
or other
-Roy
-Roy
Signed-off-by: Roy Li
---
.../libxml/libxml-sax-writer-perl_0.54.bb | 25
1 file changed, 25 insertions(+)
create mode 100644
meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
diff --git
a/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
new file mode 100644
index 000..52458e4
--- /dev/null
+++ b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
@@ -0,0 +1,25 @@
+SUMMARY = "XML::SAX::Writer - SAX2 Writer"
+DESCRIPTION = "\
+XML::SAX::Writer helps to serialize SAX2 representations of XML
documents to \
+strings, files, and other flat representations. It handles charset
encodings, \
+XML escaping conventions, and so forth. It is still considered alpha, \
+although it has been put to limited use in settings such as
XML::LibXML and \
+the AxKit XML Application Server. \
+"
+SECTION = "libs"
+LICENSE = "Artistic-1.0 | GPLv1+"
+HOMEPAGE = "http://search.cpan.org/dist/XML-SAX-Writer/";
+DEPENDS += "libxml-filter-buffertext-perl-native"
+RDEPENDS_${PN} += "libxml-filter-buffertext-perl"
+
+SRC_URI =
"http://search.cpan.org/CPAN/authors/id/P/PE/PERIGRIN/XML-SAX-Writer-${PV}.tar.gz";
+SRC_URI[md5sum] = "383139d76418a82b9800dc4f8b568891"
+SRC_URI[sha256sum] =
"a1b4d959aed8f8337523c4cef4b431e56e619c795dc6f99a868548952101cf3d"
+
+LIC_FILES_CHKSUM =
"file://README;beginline=45;endline=46;md5=d41d8cd98f00b204e9800998ecf8427e"
+
+S = "${WORKDIR}/XML-SAX-Writer-${PV}"
+
+inherit cpan allarch
+
+BBCLASSEXTEND = "native"
--
1.7.10.4
--
___
Openembedded-devel mailing list
openembedded-de...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Best Reagrds,
Roy | RongQing Li
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3 0/1] gcc-4.9.inc: fix parallel building failure
Changed in V3: Rebase it against master as we have already merged the first version. Change in V2: As the upstream of gcc suggested: - The previous fix is too hack; - Use '$(ALL_HOST_OBJS) : | $(generated_files)' rule to handle the dependency. Test Steps: 1. For reproducing the issue every time, manually modify gcc/Makefile.in to delay the generation of config.h: ... diff --git a/gcc/Makefile.in b/gcc/Makefile.in index c4daf69..c502898 100644 --- gcc-4.9.0/gcc/Makefile.in +++ gcc-4.9.0/gcc/Makefile.in @@ -1622,9 +1622,12 @@ tm.h: cs-tm.h ; @true tm_p.h: cs-tm_p.h ; @true cs-config.h: Makefile + @echo "start to generate config.h `date`" + sleep 10 TARGET_CPU_DEFAULT="" \ HEADERS="$(host_xm_include_list)" DEFINES="$(host_xm_defines)" \ $(SHELL) $(srcdir)/mkconfig.sh config.h + @echo "config.h generated `date`" cs-bconfig.h: Makefile TARGET_CPU_DEFAULT="" \ ... 2. bitbake gcc-cross-arm //Hongxu The following changes since commit addeef1dc91306175824b1f5587e40a22773cff4: lib/oe/rootfs: Improve error message whitespace (2014-07-28 12:21:24 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-gcc http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-gcc Hongxu Jia (1): gcc-4.9.inc: fix parallel building failure ...Makefile.in-fix-parallel-building-failure.patch | 79 -- 1 file changed, 42 insertions(+), 37 deletions(-) -- 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/1] gcc-4.9.inc: fix parallel building failure
The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included config.h which was a generated file. But no explicity rule to clarify the dependency. There was potential building failure while parallel make. For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the '$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these objects. For errors.o, it is part of gengtype, and the gengtype generator program is special: Two versions are built. One is for the build machine, and one is for the host. We refered what gengtype-parse.o did (which also is part of gengtype). [YOCTO #6568] Signed-off-by: Hongxu Jia --- ...Makefile.in-fix-parallel-building-failure.patch | 79 -- 1 file changed, 42 insertions(+), 37 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch b/meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch index 213820a..4c98ca2 100644 --- a/meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch +++ b/meta/recipes-devtools/gcc/gcc-4.9/0054-gcc-Makefile.in-fix-parallel-building-failure.patch @@ -1,56 +1,61 @@ gcc/Makefile.in: fix parallel building failure -Most C source files included config.h which was generated by a rule. -But no related prerequisites was added to the C source compiling rule. -There was potential building failure while makefile enabled parallel. +The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included +config.h which was a generated file. But no explicity rule +to clarify the dependency. There was potential building +failure while parallel make. -The C source compiling rule used suffix rule '.c.o', but the suffix -rule doesn't support prerequisites. -https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html +For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C +source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the +'$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these +objects. -We used the pattern rule '%.o : %.c' to instead, and add the config.h -as its prerequisite +For errors.o, it is part of gengtype, and the gengtype generator program +is special: Two versions are built. One is for the build machine, and one +is for the host. We refered what gengtype-parse.o did (which also is part +of gengtype). -We also moved the '%.o : %.c' rule down to the 'build/%.o :' rule, which -makes '%.o : %.c' rule doesn't override 'build/%.o :'. +[GCC #61899] +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61899 -Upstream-Status: Pending +Upstream-Status: Send to gcc-patc...@gcc.gnu.org mailing list Signed-off-by: Hongxu Jia --- - gcc/Makefile.in | 12 - 1 file changed, 8 insertions(+), 4 deletions(-) + gcc/Makefile.in | 7 ++- + 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in -index 6475cba..04889fe 100644 +index 6475cba..56e50bb 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in -@@ -1054,10 +1054,6 @@ COMPILE = source='$<' object='$@' libtool=no \ - POSTCOMPILE = - endif +@@ -1481,13 +1481,16 @@ OBJS-libcommon-target = $(common_out_object_file) prefix.o params.o \ + opts.o opts-common.o options.o vec.o hooks.o common/common-targhooks.o \ + hash-table.o file-find.o --.cc.o .c.o: -- $(COMPILE) $< -- $(POSTCOMPILE) -- - # - # Support for additional languages (other than C). - # C can be supported this way too (leave for later). -@@ -2342,6 +2338,14 @@ build/%.o : # dependencies provided by explicit rule later - $(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \ - -o $@ $< - -+%.o: %.c $(CONFIG_H) -+ $(COMPILE) $< -+ $(POSTCOMPILE) ++# Objects compiled from one C source file gcc-ar.c ++OBJS-gcc-ar = gcc-ar.o gcc-nm.o gcc-ranlib.o + -+%.o: %.cc $(CONFIG_H) -+ $(COMPILE) $< -+ $(POSTCOMPILE) + # This lists all host objects for the front ends. + ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) + + ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \ + $(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \ + $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \ +- lto-wrapper.o ++ lto-wrapper.o $(OBJS-gcc-ar) + + # This lists all host object files, whether they are included in this + # compilation or not. +@@ -2437,6 +2440,8 @@ gengtype-parse.o: $(CONFIG_H) + CFLAGS-build/gengtype-parse.o += -DGENERATOR_FILE + build/gengtype-parse.o: $(BCONFIG_H) + ++errors.o : $(CONFIG_H) + - ## build/version.o is compiled by the $(COMPILER_FOR_BUILD) but needs - ## several C macro definitions, just like version.o - build/version.o: version.c version.h \ + gengtype-state.o build/gengtype-state.o: gengtype-state.c $(SYSTEM_H) \ + gengtype.h errors.h double-int.h version.h $(HASHTAB_H
Re: [OE-core] [PATCH 1/3] volatile-binds: add recipe
On 07/28/2014 09:00 PM, Burton, Ross wrote:
On 28 July 2014 06:34, Chen Qi wrote:
+# This package is only for systemd based systems. So building it with 'systemd'
+# missing in DISTRO_FEATURES makes no sense.
+python () {
+if not bb.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
+raise bb.parse.SkipPackage("'systemd' not in DISTRO_FEATURES")
+}
There's a class to help with this: distro_features_check.bbclass.
Ross
Got it. I'll send out a V2.
Thanks!
//Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] systemd: add volatile-binds to RDEPENDS
On 07/28/2014 09:21 PM, Richard Purdie wrote:
On Mon, 2014-07-28 at 13:34 +0800, Chen Qi wrote:
---
meta/recipes-core/systemd/systemd_213.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/systemd/systemd_213.bb
b/meta/recipes-core/systemd/systemd_213.bb
index 5de7cdc..4fb7ffc 100644
--- a/meta/recipes-core/systemd/systemd_213.bb
+++ b/meta/recipes-core/systemd/systemd_213.bb
@@ -243,6 +243,7 @@ FILES_${PN}-dbg += "${rootlibdir}/.debug
${systemd_unitdir}/.debug ${systemd_uni
FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/
${sysconfdir}/rpm/macros.systemd"
RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})"
+RDEPENDS_${PN} += "volatile-binds"
RRECOMMENDS_${PN} += "systemd-serialgetty systemd-compat-units udev-hwdb\
util-linux-agetty \
Do we always need/want to include this? Does this have any implications
for rw systems? I couldn't immediately see how this triggers on a ro
system...
Cheers,
Richard
Hi Richard,
Take var-lib-volatile.service as an example.
In the service file, we have:
ConditionPathIsReadWrite=!/var/lib
So if /var/lib is rw, the service is not started. On a ro system,
/var/lib is read-only, and the service is started.
I just realized that I didn't put comments in these patches.
I'll send out a V2.
Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3 1/1] systemd: upgrade to 215
Upgrade systemd from 213 to 215.
systemd-older-kernel.patch is removed as it's fixed in 215.
Signed-off-by: Chen Qi
---
.../systemd/systemd/systemd-older-kernel.patch | 56
.../systemd/{systemd_213.bb => systemd_215.bb} |8 +--
2 files changed, 4 insertions(+), 60 deletions(-)
delete mode 100644 meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
rename meta/recipes-core/systemd/{systemd_213.bb => systemd_215.bb} (99%)
diff --git a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
b/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
deleted file mode 100644
index 18b50e7..000
--- a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 6109f02dcc4f2d7a461c5772bab494f5753a2203 Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Thu, 29 May 2014 08:09:07 +
-Subject: [PATCH] rtnl-types.c: check IFLA_VLAN_PROTOCOL
-
-The older kernel's linux/if_link.h doesn't have IFLA_VLAN_PROTOCOL, we need
-check whether it has been defined or not.
-
-The maintainer said that he would fix it:
-
-http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/18200
-
-Also we need redefine IFLA_MAX from 34 to 35 when define IFLA_CARRIER,
-otherwise there would be error:
-
-| src/libsystemd/sd-rtnl/rtnl-types.c:233:9: error: array index in initializer
exceeds array bounds
-| [IFLA_CARRIER] = { .type = NLA_U8 },
-
-Upstream-Status: Pending
-
-Signed-off-by: Robert Yang
- src/libsystemd/sd-rtnl/rtnl-types.c | 2 ++
- src/shared/missing.h| 2 ++
- 2 files changed, 4 insertions(+)
-
-diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
-index 44ac5ec..ab6161f 100644
a/src/libsystemd/sd-rtnl/rtnl-types.c
-+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
-@@ -67,7 +67,9 @@ static const NLType
rtnl_link_info_data_vlan_types[IFLA_VLAN_MAX + 1] = {
- [IFLA_VLAN_EGRESS_QOS] = { .type = NLA_NESTED },
- [IFLA_VLAN_INGRESS_QOS] = { .type = NLA_NESTED },
- */
-+#ifdef IFLA_VLAN_PROTOCOL
- [IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
-+#endif
- };
-
- static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
-diff --git a/src/shared/missing.h b/src/shared/missing.h
-index d5ec2f8..732853f 100644
a/src/shared/missing.h
-+++ b/src/shared/missing.h
-@@ -94,6 +94,8 @@
-
- #ifndef IFLA_CARRIER
- #define IFLA_CARRIER 33
-+ #undef IFLA_MAX
-+ #define IFLA_MAX 35
- #ifndef IFLA_NUM_RX_QUEUES
- #define IFLA_NUM_RX_QUEUES 32
- #ifndef IFLA_NUM_TX_QUEUES
---
-1.8.3.4
-
diff --git a/meta/recipes-core/systemd/systemd_213.bb
b/meta/recipes-core/systemd/systemd_215.bb
similarity index 99%
rename from meta/recipes-core/systemd/systemd_213.bb
rename to meta/recipes-core/systemd/systemd_215.bb
index 5de7cdc..b1ffbdd 100644
--- a/meta/recipes-core/systemd/systemd_213.bb
+++ b/meta/recipes-core/systemd/systemd_215.bb
@@ -17,9 +17,9 @@ SECTION = "base/shell"
inherit gtk-doc useradd pkgconfig autotools perlnative update-rc.d
update-alternatives qemu systemd ptest
-SRCREV = "c9679c652b3c31f2510e8805d81630680ebc7e95"
+SRCREV = "252ff40a3827b4e8e62e03a5e2f80da3fe02bee6"
-PV = "213+git${SRCPV}"
+PV = "215+git${SRCPV}"
SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=git \
file://binfmt-install.patch \
@@ -35,8 +35,7 @@ SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=
file://00-create-volatile.conf \
file://init \
file://run-ptest \
- file://systemd-older-kernel.patch \
- "
+ "
S = "${WORKDIR}/git"
@@ -231,6 +230,7 @@ FILES_${PN} = " ${base_bindir}/* \
${exec_prefix}/lib/systemd \
${exec_prefix}/lib/modules-load.d \
${exec_prefix}/lib/sysctl.d \
+${exec_prefix}/lib/sysusers.d \
${localstatedir} \
/lib/udev/rules.d/70-uaccess.rules \
/lib/udev/rules.d/71-seat.rules \
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3 0/1] systemd: upgrade to 215
The following changes since commit 58f08a96764094189b5aaf3cc8b4cc0c95e23409:
gst-ffmpeg: Add CVE patches (2014-07-23 21:57:04 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd_215
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd_215
Chen Qi (1):
systemd: upgrade to 215
.../systemd/systemd/systemd-older-kernel.patch | 56
.../systemd/{systemd_213.bb => systemd_215.bb} |8 +--
2 files changed, 4 insertions(+), 60 deletions(-)
delete mode 100644 meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
rename meta/recipes-core/systemd/{systemd_213.bb => systemd_215.bb} (99%)
--
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] alsa-lib: Add RPROVIDES for alsa-dev
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Monday, July 28, 2014 10:24 PM
> To: Huang, Jie (Jackie)
> Cc: OE-core
> Subject: Re: [OE-core] [PATCH] alsa-lib: Add RPROVIDES for alsa-dev
>
> On 28 July 2014 15:19, wrote:
> > +RPROVIDES_${PN}-dev = "alsa-dev"
>
> I believe you'll want replaces and conflicts too, so that alsa-dev gets
> removed.
Thanks for pointing this, but I think I'm still not fully understand what's
required to get a package
removed, I referred to the commit " 4bac11f util-linux: remove non PN based
-dev packages"
and thought adding the RPROVIDES is enough, would you mind explaining a little
more?
Thanks,
Jackie
>
> Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/3] Support 'read-only-rootfs' IMAGE_FEATURES for systemd based systems
This patchset mainly comes from https://github.com/MentorEmbedded/meta-ro-rootfs with only a little modification. //Chen Qi The following changes since commit 3f7fcbc167c13bdaa6c12a81c7851530d72f02e0: directfb-examples: Fix building with new autoconf (2014-07-27 08:30:13 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd_readonly http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd_readonly Chen Qi (3): volatile-binds: add recipe systemd: add volatile-binds to RDEPENDS image.bbclass: tweak read_only_rootfs_hook to also support systemd based systems meta/classes/image.bbclass |5 +- meta/recipes-core/systemd/systemd_213.bb |1 + meta/recipes-core/volatile-binds/files/COPYING.MIT | 17 + .../volatile-binds/files/mount-copybind| 34 ++ .../volatile-binds/files/volatile-binds.service.in | 19 ++ meta/recipes-core/volatile-binds/volatile-binds.bb | 69 6 files changed, 143 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-core/volatile-binds/files/COPYING.MIT create mode 100755 meta/recipes-core/volatile-binds/files/mount-copybind create mode 100644 meta/recipes-core/volatile-binds/files/volatile-binds.service.in create mode 100644 meta/recipes-core/volatile-binds/volatile-binds.bb -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 2/3] systemd: add volatile-binds to RDEPENDS
This services generated from volatile-binds.bb recipe file only have
effect in a read-only filesystem. So if the rootfs is read-write, the
related service are not started.
Signed-off-by: Chen Qi
---
meta/recipes-core/systemd/systemd_213.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/systemd/systemd_213.bb
b/meta/recipes-core/systemd/systemd_213.bb
index 5de7cdc..4fb7ffc 100644
--- a/meta/recipes-core/systemd/systemd_213.bb
+++ b/meta/recipes-core/systemd/systemd_213.bb
@@ -243,6 +243,7 @@ FILES_${PN}-dbg += "${rootlibdir}/.debug
${systemd_unitdir}/.debug ${systemd_uni
FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/
${sysconfdir}/rpm/macros.systemd"
RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})"
+RDEPENDS_${PN} += "volatile-binds"
RRECOMMENDS_${PN} += "systemd-serialgetty systemd-compat-units udev-hwdb\
util-linux-agetty \
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 3/3] image.bbclass: tweak read_only_rootfs_hook to also support systemd based systems
Modify the read_only_rootfs_hook function to make it also have effect
on systemd based systems.
Signed-off-by: Chen Qi
---
meta/classes/image.bbclass |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index da13bb8..82605f2 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -199,9 +199,10 @@ do_rootfs[umask] = "022"
# A hook function to support read-only-rootfs IMAGE_FEATURES
# Currently, it only supports sysvinit system.
read_only_rootfs_hook () {
+ # Tweak the mount option and fs_passno for rootfs in fstab
+ sed -i -e
'/^[#[:space:]]*\/dev\/root/{s/defaults/ro/;s/\([[:space:]]*[[:digit:]]\)\([[:space:]]*\)[[:digit:]]$/\1\20/}'
${IMAGE_ROOTFS}/etc/fstab
+
if ${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "true", "false",
d)}; then
- # Tweak the mount option and fs_passno for rootfs in fstab
- sed -i -e
'/^[#[:space:]]*\/dev\/root/{s/defaults/ro/;s/\([[:space:]]*[[:digit:]]\)\([[:space:]]*\)[[:digit:]]$/\1\20/}'
${IMAGE_ROOTFS}/etc/fstab
# Change the value of ROOTFS_READ_ONLY in /etc/default/rcS to
yes
if [ -e ${IMAGE_ROOTFS}/etc/default/rcS ]; then
sed -i 's/ROOTFS_READ_ONLY=no/ROOTFS_READ_ONLY=yes/'
${IMAGE_ROOTFS}/etc/default/rcS
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/3] volatile-binds: add recipe
This recipe is designed to play a key role in a read-only rootfs
of systemd based systems. It generates service files from a template,
volatile-binds.service.in and the VOLATILE_BINDS variable.
By default, VOLATILE_BINDS takes the value of "/var/volatile/lib /var/lib\n",
which leads to the generation of volatile-var-lib.service file.
This file doesn't have any effect in a read-write system, as it
has "ConditionPathIsReadWrite = !/var/lib" in the [Unit] section.
In other words, this file only has effect in a read-only rootfs.
Signed-off-by: Chen Qi
---
meta/recipes-core/volatile-binds/files/COPYING.MIT | 17 +
.../volatile-binds/files/mount-copybind| 34 ++
.../volatile-binds/files/volatile-binds.service.in | 19 ++
meta/recipes-core/volatile-binds/volatile-binds.bb | 69
4 files changed, 139 insertions(+)
create mode 100644 meta/recipes-core/volatile-binds/files/COPYING.MIT
create mode 100755 meta/recipes-core/volatile-binds/files/mount-copybind
create mode 100644
meta/recipes-core/volatile-binds/files/volatile-binds.service.in
create mode 100644 meta/recipes-core/volatile-binds/volatile-binds.bb
diff --git a/meta/recipes-core/volatile-binds/files/COPYING.MIT
b/meta/recipes-core/volatile-binds/files/COPYING.MIT
new file mode 100644
index 000..7e7d574
--- /dev/null
+++ b/meta/recipes-core/volatile-binds/files/COPYING.MIT
@@ -0,0 +1,17 @@
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
+SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
+DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
+THE USE OR OTHER DEALINGS IN THE SOFTWARE.
diff --git a/meta/recipes-core/volatile-binds/files/mount-copybind
b/meta/recipes-core/volatile-binds/files/mount-copybind
new file mode 100755
index 000..2aeaf84
--- /dev/null
+++ b/meta/recipes-core/volatile-binds/files/mount-copybind
@@ -0,0 +1,34 @@
+#!/bin/sh
+#
+# Perform a bind mount, copying existing files as we do so to ensure the
+# overlaid path has the necessary content.
+
+if [ $# -lt 2 ]; then
+echo >&2 "Usage: $0 spec mountpoint [OPTIONS]"
+exit 1
+fi
+
+spec=$1
+mountpoint=$2
+
+if [ $# -gt 2 ]; then
+options=$3
+else
+options=
+fi
+
+[ -n "$options" ] && options=",$options"
+
+mkdir -p "${spec%/*}"
+if [ -d "$mountpoint" ]; then
+if [ ! -d "$spec" ]; then
+mkdir "$spec"
+cp -pPR "$mountpoint"/. "$spec/"
+fi
+elif [ -f "$mountpoint" ]; then
+if [ ! -f "$spec" ]; then
+cp -pP "$mountpoint" "$spec"
+fi
+fi
+
+mount -o "bind$options" "$spec" "$mountpoint"
diff --git a/meta/recipes-core/volatile-binds/files/volatile-binds.service.in
b/meta/recipes-core/volatile-binds/files/volatile-binds.service.in
new file mode 100644
index 000..32be5b4
--- /dev/null
+++ b/meta/recipes-core/volatile-binds/files/volatile-binds.service.in
@@ -0,0 +1,19 @@
+[Unit]
+Description=Bind mount volatile @where@
+DefaultDependencies=false
+Before=local-fs.target
+RequiresMountsFor=@whatparent@ @whereparent@
+ConditionPathIsReadWrite=@whatparent@
+ConditionPathExists=@where@
+ConditionPathIsReadWrite=!@where@
+
+[Service]
+Type=oneshot
+RemainAfterExit=Yes
+StandardOutput=syslog
+TimeoutSec=0
+ExecStart=/sbin/mount-copybind @what@ @where@
+ExecStop=/sbin/umount @where@
+
+[Install]
+WantedBy=local-fs.target
diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb
b/meta/recipes-core/volatile-binds/volatile-binds.bb
new file mode 100644
index 000..4080ff7
--- /dev/null
+++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
@@ -0,0 +1,69 @@
+SUMMARY = "Volatile bind mount setup and configuration for read-only-rootfs"
+DESCRIPTION = "${SUMMARY}"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://../COPYING.MIT;md5=5750f3aa4ea2b00c2bf21b2b2a7b714d"
+
+SRC_URI = "\
+file://mount-copybind \
+file://COPYING.MIT \
+file://volatile-binds.service.in \
+"
+
+inherit allarch systemd distro_features_check
+
+REQUIRED_DISTRO_FEATURES = "systemd"
+
+VOLATILE_BINDS ?= "\
+/var/volatile/lib /var/lib\n\
+"
+VOLATILE_BINDS[type] = "list"
+VOLATILE_BINDS[separator] = "\n"
+
+def volatile_systemd_services(d):
+services = []
+
Re: [OE-core] [PATCH V3 1/1] systemd: upgrade to 215
On 07/28/2014 07:12 PM, Chen Qi wrote:
Upgrade systemd from 213 to 215.
systemd-older-kernel.patch is removed as it's fixed in 215.
I had a failure like this from the V2 Patch, has this been addressed:
| cc1: warning: ./src/core: No such file or directory
| make[1]: *** [all-recursive] Error 1
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| WARNING:
/srv/hdd/builds/world/tmp/work/ppc7400-poky-linux/systemd/1_215+gitAUTOINC+252ff40a38-r0/temp/run.do_compile.687:1
exit 1 from
| exit 1
| ERROR: Function failed: do_compile (log file is located at
/srv/hdd/builds/world/tmp/work/ppc7400-poky-linux/systemd/1_215+gitAUTOINC+252ff40a38-r0/temp/log.do_compile.687)
Sau!
Signed-off-by: Chen Qi
---
.../systemd/systemd/systemd-older-kernel.patch | 56
.../systemd/{systemd_213.bb => systemd_215.bb} |8 +--
2 files changed, 4 insertions(+), 60 deletions(-)
delete mode 100644
meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
rename meta/recipes-core/systemd/{systemd_213.bb => systemd_215.bb} (99%)
diff --git a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
b/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
deleted file mode 100644
index 18b50e7..000
--- a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 6109f02dcc4f2d7a461c5772bab494f5753a2203 Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Thu, 29 May 2014 08:09:07 +
-Subject: [PATCH] rtnl-types.c: check IFLA_VLAN_PROTOCOL
-
-The older kernel's linux/if_link.h doesn't have IFLA_VLAN_PROTOCOL, we need
-check whether it has been defined or not.
-
-The maintainer said that he would fix it:
-
-http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/18200
-
-Also we need redefine IFLA_MAX from 34 to 35 when define IFLA_CARRIER,
-otherwise there would be error:
-
-| src/libsystemd/sd-rtnl/rtnl-types.c:233:9: error: array index in initializer
exceeds array bounds
-| [IFLA_CARRIER] = { .type = NLA_U8 },
-
-Upstream-Status: Pending
-
-Signed-off-by: Robert Yang
- src/libsystemd/sd-rtnl/rtnl-types.c | 2 ++
- src/shared/missing.h| 2 ++
- 2 files changed, 4 insertions(+)
-
-diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
-index 44ac5ec..ab6161f 100644
a/src/libsystemd/sd-rtnl/rtnl-types.c
-+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
-@@ -67,7 +67,9 @@ static const NLType
rtnl_link_info_data_vlan_types[IFLA_VLAN_MAX + 1] = {
- [IFLA_VLAN_EGRESS_QOS] = { .type = NLA_NESTED },
- [IFLA_VLAN_INGRESS_QOS] = { .type = NLA_NESTED },
- */
-+#ifdef IFLA_VLAN_PROTOCOL
- [IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
-+#endif
- };
-
- static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
-diff --git a/src/shared/missing.h b/src/shared/missing.h
-index d5ec2f8..732853f 100644
a/src/shared/missing.h
-+++ b/src/shared/missing.h
-@@ -94,6 +94,8 @@
-
- #ifndef IFLA_CARRIER
- #define IFLA_CARRIER 33
-+ #undef IFLA_MAX
-+ #define IFLA_MAX 35
- #ifndef IFLA_NUM_RX_QUEUES
- #define IFLA_NUM_RX_QUEUES 32
- #ifndef IFLA_NUM_TX_QUEUES
---
-1.8.3.4
-
diff --git a/meta/recipes-core/systemd/systemd_213.bb
b/meta/recipes-core/systemd/systemd_215.bb
similarity index 99%
rename from meta/recipes-core/systemd/systemd_213.bb
rename to meta/recipes-core/systemd/systemd_215.bb
index 5de7cdc..b1ffbdd 100644
--- a/meta/recipes-core/systemd/systemd_213.bb
+++ b/meta/recipes-core/systemd/systemd_215.bb
@@ -17,9 +17,9 @@ SECTION = "base/shell"
inherit gtk-doc useradd pkgconfig autotools perlnative update-rc.d
update-alternatives qemu systemd ptest
-SRCREV = "c9679c652b3c31f2510e8805d81630680ebc7e95"
+SRCREV = "252ff40a3827b4e8e62e03a5e2f80da3fe02bee6"
-PV = "213+git${SRCPV}"
+PV = "215+git${SRCPV}"
SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=git \
file://binfmt-install.patch \
@@ -35,8 +35,7 @@ SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=
file://00-create-volatile.conf \
file://init \
file://run-ptest \
- file://systemd-older-kernel.patch \
- "
+ "
S = "${WORKDIR}/git"
@@ -231,6 +230,7 @@ FILES_${PN} = " ${base_bindir}/* \
${exec_prefix}/lib/systemd \
${exec_prefix}/lib/modules-load.d \
${exec_prefix}/lib/sysctl.d \
+${exec_prefix}/lib/sysusers.d \
${localstatedir} \
/lib/udev/rules.d/70-uaccess.rules \
/lib/udev/rules.d/71-seat.rules \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 1/1] systemd: upgrade to 215
On 07/29/2014 12:19 PM, Saul Wold wrote:
On 07/28/2014 07:12 PM, Chen Qi wrote:
Upgrade systemd from 213 to 215.
systemd-older-kernel.patch is removed as it's fixed in 215.
I had a failure like this from the V2 Patch, has this been addressed:
No. I haven't seen this error.
Could you give me a link to the whole error log?
Best Regards,
Chen Qi
| cc1: warning: ./src/core: No such file or directory
| make[1]: *** [all-recursive] Error 1
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| WARNING:
/srv/hdd/builds/world/tmp/work/ppc7400-poky-linux/systemd/1_215+gitAUTOINC+252ff40a38-r0/temp/run.do_compile.687:1
exit 1 from
| exit 1
| ERROR: Function failed: do_compile (log file is located at
/srv/hdd/builds/world/tmp/work/ppc7400-poky-linux/systemd/1_215+gitAUTOINC+252ff40a38-r0/temp/log.do_compile.687)
Sau!
Signed-off-by: Chen Qi
---
.../systemd/systemd/systemd-older-kernel.patch | 56
.../systemd/{systemd_213.bb => systemd_215.bb} |8 +--
2 files changed, 4 insertions(+), 60 deletions(-)
delete mode 100644
meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
rename meta/recipes-core/systemd/{systemd_213.bb => systemd_215.bb}
(99%)
diff --git
a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
b/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
deleted file mode 100644
index 18b50e7..000
--- a/meta/recipes-core/systemd/systemd/systemd-older-kernel.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 6109f02dcc4f2d7a461c5772bab494f5753a2203 Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Thu, 29 May 2014 08:09:07 +
-Subject: [PATCH] rtnl-types.c: check IFLA_VLAN_PROTOCOL
-
-The older kernel's linux/if_link.h doesn't have IFLA_VLAN_PROTOCOL,
we need
-check whether it has been defined or not.
-
-The maintainer said that he would fix it:
-
-http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/18200
-
-Also we need redefine IFLA_MAX from 34 to 35 when define IFLA_CARRIER,
-otherwise there would be error:
-
-| src/libsystemd/sd-rtnl/rtnl-types.c:233:9: error: array index in
initializer exceeds array bounds
-| [IFLA_CARRIER] = { .type = NLA_U8 },
-
-Upstream-Status: Pending
-
-Signed-off-by: Robert Yang
- src/libsystemd/sd-rtnl/rtnl-types.c | 2 ++
- src/shared/missing.h| 2 ++
- 2 files changed, 4 insertions(+)
-
-diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
-index 44ac5ec..ab6161f 100644
a/src/libsystemd/sd-rtnl/rtnl-types.c
-+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
-@@ -67,7 +67,9 @@ static const NLType
rtnl_link_info_data_vlan_types[IFLA_VLAN_MAX + 1] = {
- [IFLA_VLAN_EGRESS_QOS] = { .type = NLA_NESTED },
- [IFLA_VLAN_INGRESS_QOS] = { .type = NLA_NESTED },
- */
-+#ifdef IFLA_VLAN_PROTOCOL
- [IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
-+#endif
- };
-
- static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX +
1] = {
-diff --git a/src/shared/missing.h b/src/shared/missing.h
-index d5ec2f8..732853f 100644
a/src/shared/missing.h
-+++ b/src/shared/missing.h
-@@ -94,6 +94,8 @@
-
- #ifndef IFLA_CARRIER
- #define IFLA_CARRIER 33
-+ #undef IFLA_MAX
-+ #define IFLA_MAX 35
- #ifndef IFLA_NUM_RX_QUEUES
- #define IFLA_NUM_RX_QUEUES 32
- #ifndef IFLA_NUM_TX_QUEUES
---
-1.8.3.4
-
diff --git a/meta/recipes-core/systemd/systemd_213.bb
b/meta/recipes-core/systemd/systemd_215.bb
similarity index 99%
rename from meta/recipes-core/systemd/systemd_213.bb
rename to meta/recipes-core/systemd/systemd_215.bb
index 5de7cdc..b1ffbdd 100644
--- a/meta/recipes-core/systemd/systemd_213.bb
+++ b/meta/recipes-core/systemd/systemd_215.bb
@@ -17,9 +17,9 @@ SECTION = "base/shell"
inherit gtk-doc useradd pkgconfig autotools perlnative update-rc.d
update-alternatives qemu systemd ptest
-SRCREV = "c9679c652b3c31f2510e8805d81630680ebc7e95"
+SRCREV = "252ff40a3827b4e8e62e03a5e2f80da3fe02bee6"
-PV = "213+git${SRCPV}"
+PV = "215+git${SRCPV}"
SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=git
\
file://binfmt-install.patch \
@@ -35,8 +35,7 @@ SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=
file://00-create-volatile.conf \
file://init \
file://run-ptest \
- file://systemd-older-kernel.patch \
- "
+ "
S = "${WORKDIR}/git"
@@ -231,6 +230,7 @@ FILES_${PN} = " ${base_bindir}/* \
${exec_prefix}/lib/systemd \
${exec_prefix}/lib/modules-load.d \
${exec_prefix}/lib/sysctl.d \
+${exec_prefix}/lib/sysusers.d \
${localstatedir} \
/lib/udev/rules.d/70-uaccess.rules \
/lib/udev/rules.d/71-seat.rules \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedde
[OE-core] Specifying MACHINE inside distro config only
I have several distro config files. I bind each of them to single machine like this: # cat conf/distro/mydistro.conf DISTRO = "mydistro" DISTRO_NAME = "My Distro" DISTRO_VERSION = "1.01" MACHINE = "cedartrail" ... I also created "conf/auto.conf" file with following content: DISTRO = "mydistro" to specify distro to build. The problem is that without specifying MACHINE in "conf/auto.conf" I get following error: ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: TUNE_ARCH is unset. Please ensure your MACHINE configuration includes a valid tune configuration file which will set this correctly. Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH ().Toolchain tunings invalid: No tuning found for default multilib. I use a script to change distro (in "auto.conf") and each distro knows its machine to build for. So specifying MACHINE in "auto.conf" isn't desirable. Can someone tell what did I miss? -- Best regards, Yevhen -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
