Re: [OE-core] [PATCH] systemd: fix /var/log/journal ownership
On 03/10/2015 11:25 AM, Jonathan Liu wrote:
The ownership needs to be explicitly set otherwise it inherits the user
and group id of the build user.
Signed-off-by: Jonathan Liu
---
meta/recipes-core/systemd/systemd_219.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index 24486f1..6a4f4e8 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -147,6 +147,8 @@ do_install() {
sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd%
${D}${sysconfdir}/init.d/systemd-udevd
fi
+ chown root:root ${D}/${localstatedir}/log/journal
+
# Delete journal README, as log can be symlinked inside volatile.
rm -f ${D}/${localstatedir}/log/README
I think it should be root:systemd-journal.
What do you think?
And this patch would also fix the following bug.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7293
Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: Instruct the journal to always be volatile
On Thu, Mar 12, 2015 at 12:09 AM, Khem Raj wrote: > >> On Mar 11, 2015, at 2:28 PM, Randy Witt wrote: >> >> When the storage mode for the journal is "auto" if /var/log/journal >> exists then the journal will flush to /var/log/journal assuming that >> /var/log/journal is persistent. >> >> However /var/log -> /var/volatile/log in poky, so even though >> /var/log/journal exists, it is still volatile. >> >> Since this can cause ordering issues due to /var/volatile needing to be >> mounted before the journal actually writes to it, just specify that the >> journal >> should always be volatile and never try to write to "persistent" >> storage. The journal will exist in /run/log/journal only. >> >> This also disables the "After" of the journal on var-volatile.mount >> since the ordering is no longer necessary when the journal is only >> stored in /run/log/journal. >> >> [Yocto #7388] > > > This is not right. What if I want persistent logs.? the options is just gone. > Both cases should work. /var/volatile should only be used > when doing ro-rfs its not FHS specified anyway. Lets not go with this patch. Agreed. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: fix /var/log/journal ownership
> On Mar 12, 2015, at 12:14 AM, ChenQi wrote:
>
> On 03/10/2015 11:25 AM, Jonathan Liu wrote:
>> The ownership needs to be explicitly set otherwise it inherits the user
>> and group id of the build user.
>>
>> Signed-off-by: Jonathan Liu
>> ---
>> meta/recipes-core/systemd/systemd_219.bb | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-core/systemd/systemd_219.bb
>> b/meta/recipes-core/systemd/systemd_219.bb
>> index 24486f1..6a4f4e8 100644
>> --- a/meta/recipes-core/systemd/systemd_219.bb
>> +++ b/meta/recipes-core/systemd/systemd_219.bb
>> @@ -147,6 +147,8 @@ do_install() {
>> sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd%
>> ${D}${sysconfdir}/init.d/systemd-udevd
>> fi
>> + chown root:root ${D}/${localstatedir}/log/journal
>> +
>> # Delete journal README, as log can be symlinked inside volatile.
>> rm -f ${D}/${localstatedir}/log/README
>>
>
> I think it should be root:systemd-journal.
> What do you think?
>
> And this patch would also fix the following bug.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7293
/var/log is symlinked (its not a copy-bind) into /var/volatile/log and
/var/volatile is mounted as tmpfs on runtime as of now
so how is this patch helping out with anything ?
>
> Regards,
> Chen Qi
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: fix /var/log/journal ownership
On 03/12/2015 03:21 PM, Khem Raj wrote:
On Mar 12, 2015, at 12:14 AM, ChenQi wrote:
On 03/10/2015 11:25 AM, Jonathan Liu wrote:
The ownership needs to be explicitly set otherwise it inherits the user
and group id of the build user.
Signed-off-by: Jonathan Liu
---
meta/recipes-core/systemd/systemd_219.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index 24486f1..6a4f4e8 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -147,6 +147,8 @@ do_install() {
sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd%
${D}${sysconfdir}/init.d/systemd-udevd
fi
+ chown root:root ${D}/${localstatedir}/log/journal
+
# Delete journal README, as log can be symlinked inside volatile.
rm -f ${D}/${localstatedir}/log/README
I think it should be root:systemd-journal.
What do you think?
And this patch would also fix the following bug.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7293
/var/log is symlinked (its not a copy-bind) into /var/volatile/log and
/var/volatile is mounted as tmpfs on runtime as of now
so how is this patch helping out with anything ?
Hmm... You are right. I think we should just delete the directory.
//Chen Qi
Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how many ways to delete/de-activate a recipe's task?
On Wed, 11 Mar 2015, Richard Purdie wrote: > On Wed, 2015-03-11 at 12:22 -0500, Mark Hatle wrote: > > On 3/11/15 11:30 AM, Robert P. J. Day wrote: > > > > > > i recall that richard purdie might have explained this once but i > > > have no idea where that post is and i need to add something to it, > > > anyway ... how many ways are there to "delete" a task from a recipe, > > > and what are the differences? > > > > > > so far, i've seen: > > > > > > 1) bitbake supports a "deltask" directive > > > > The task and all it's dependencies go away. So anything dependent on it > > and the > > things it depends on, are no longer dependent. > > > > > 2) you can use the [noexec] task flag > > > > The task and it's dependencies remain, but nothing is executed. > > > > > 3) i've also seen redefining the task with a no-op ":" command > > > > The task is executed and does nothing. (I believe this dumps a stamp file > > and > > the noexec does not.. but I may be wrong.) > > What Mark said. 3) is the old way of doing 2), we added 2) to make > it more efficient since there is no task execution overhead (which > at one point was measurable, it may be less so now). so that first part -- that 2) is a newer, tidier(?) way of doing 3) -- is pretty much what i remember from once upon a time. good. as for 1), i'm still confused by that explanation. say we have the dependency chain A -> B -> C ... A depends on B which depends on C. if i "deltask B", then any dependency links which involve B will disappear, both incoming and outgoing in the DAG. but will A be adjusted to now depend on C? (i'm guessing not, just want to be sure.) finally, is it just a matter of personal taste whether one deletes a task using "deltask" or uses [noexec]? i'm looking at examples under OE and here are a couple. clearly, for image.bbclass, there are a *pile* of tasks that are not relevant, so the following makes sense: meta/classes/image.bbclass:do_fetch[noexec] = "1" meta/classes/image.bbclass:do_unpack[noexec] = "1" meta/classes/image.bbclass:do_patch[noexec] = "1" meta/classes/image.bbclass:do_configure[noexec] = "1" meta/classes/image.bbclass:do_compile[noexec] = "1" meta/classes/image.bbclass:do_install[noexec] = "1" meta/classes/image.bbclass:do_populate_sysroot[noexec] = "1" meta/classes/image.bbclass:do_package[noexec] = "1" meta/classes/image.bbclass:do_package_qa[noexec] = "1" meta/classes/image.bbclass:do_packagedata[noexec] = "1" meta/classes/image.bbclass:do_package_write_ipk[noexec] = "1" meta/classes/image.bbclass:do_package_write_deb[noexec] = "1" meta/classes/image.bbclass:do_package_write_rpm[noexec] = "1" meta/classes/image.bbclass:do_bundle_initramfs[noexec] = "1" similarly, for native.bbclass, the following also makes sense, but uses "deltask": meta/classes/native.bbclass:deltask package meta/classes/native.bbclass:deltask packagedata meta/classes/native.bbclass:deltask package_qa meta/classes/native.bbclass:deltask package_write_ipk meta/classes/native.bbclass:deltask package_write_deb meta/classes/native.bbclass:deltask package_write_rpm meta/classes/native.bbclass:deltask package_write so why does the first use [noexec] and the second use deltask? is there a functional difference? rday p.s. i believe i appreciate the difference in *mechanics* of the above. [noexec] doesn't affect the DAG of task dependencies, it simply turns off the execution of that recipe-specific task, while "deltask" affects the actual underlying task DAG. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: Instruct the journal to always be volatile
On Thu, 2015-03-12 at 04:18 -0300, Otavio Salvador wrote: > On Thu, Mar 12, 2015 at 12:09 AM, Khem Raj wrote: > > > >> On Mar 11, 2015, at 2:28 PM, Randy Witt > >> wrote: > >> > >> When the storage mode for the journal is "auto" if /var/log/journal > >> exists then the journal will flush to /var/log/journal assuming that > >> /var/log/journal is persistent. > >> > >> However /var/log -> /var/volatile/log in poky, so even though > >> /var/log/journal exists, it is still volatile. > >> > >> Since this can cause ordering issues due to /var/volatile needing to be > >> mounted before the journal actually writes to it, just specify that the > >> journal > >> should always be volatile and never try to write to "persistent" > >> storage. The journal will exist in /run/log/journal only. > >> > >> This also disables the "After" of the journal on var-volatile.mount > >> since the ordering is no longer necessary when the journal is only > >> stored in /run/log/journal. > >> > >> [Yocto #7388] > > > > > > This is not right. What if I want persistent logs.? the options is just > > gone. Both cases should work. /var/volatile should only be used > > when doing ro-rfs its not FHS specified anyway. Lets not go with this patch. > > Agreed. This isn't quite so simple as "agreed". Are we saying that we want to rework volatiles handling after feature freeze? My view on this is that yes, we do need to do something about it, but right now during stabilisation is not the right time. Particularly when the patches proposed aren't even tested with sysvinit. So I'm interested in patches which make things work better without making fundamental changes now. We can look at changing volatiles with a properly thought out plan in the next development cycle. Making the systemd configuration match the rest of the default system setup would seem to be sensible. We should make it possible for others to override that if their setup isn't volatile. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devshell: start in ${B} not ${S}
On Tue, Mar 10, 2015 at 3:57 PM, Andre McCurdy wrote:
> On Tue, Mar 10, 2015 at 10:50 AM, Ross Burton wrote:
>> When S=B this is a no-op, but when B!=S this means you can run make and so on
>> without having to change directory first.
>
> Just my opinion, but I'd vote against this change. Running
> "../temp/run.do_compile" works from either directory but editing
> sources and running "quilt refresh" etc only works from ${S}.
+1
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] meta/lib/oe/package.py: Fix for bug 7428
This fix solves the problem with the ownership of files in packages. The do_install task was producing correct and expected output but when the files were being put in, e.g. a rpm package, the ownership could be different than that in the do_install task. Signed-off-by: Peter Kjellerstedt Signed-off-by: Fabrice Coulon --- meta/lib/oe/package.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index 7c728fc..8bc56c6 100644 --- a/meta/lib/oe/package.py +++ b/meta/lib/oe/package.py @@ -31,7 +31,7 @@ def runstrip(arg): extraflags = "--remove-section=.comment --remove-section=.note" # Use mv to break hardlinks -stripcmd = "'%s' %s '%s' -o '%s.tmp' && mv '%s.tmp' '%s'" % (strip, extraflags, file, file, file, file) +stripcmd = "'%s' %s '%s' -o '%s.tmp' && chown --reference='%s' '%s.tmp' && mv '%s.tmp' '%s'" % (strip, extraflags, file, file, file, file, file, file) bb.debug(1, "runstrip: %s" % stripcmd) ret = subprocess.call(stripcmd, shell=True) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: Instruct the journal to always be volatile
On Thu, Mar 12, 2015 at 5:04 AM, Richard Purdie wrote: > On Thu, 2015-03-12 at 04:18 -0300, Otavio Salvador wrote: >> On Thu, Mar 12, 2015 at 12:09 AM, Khem Raj wrote: >> > >> >> On Mar 11, 2015, at 2:28 PM, Randy Witt >> >> wrote: >> >> >> >> When the storage mode for the journal is "auto" if /var/log/journal >> >> exists then the journal will flush to /var/log/journal assuming that >> >> /var/log/journal is persistent. >> >> >> >> However /var/log -> /var/volatile/log in poky, so even though >> >> /var/log/journal exists, it is still volatile. >> >> >> >> Since this can cause ordering issues due to /var/volatile needing to be >> >> mounted before the journal actually writes to it, just specify that the >> >> journal >> >> should always be volatile and never try to write to "persistent" >> >> storage. The journal will exist in /run/log/journal only. >> >> >> >> This also disables the "After" of the journal on var-volatile.mount >> >> since the ordering is no longer necessary when the journal is only >> >> stored in /run/log/journal. >> >> >> >> [Yocto #7388] >> > >> > >> > This is not right. What if I want persistent logs.? the options is just >> > gone. Both cases should work. /var/volatile should only be used >> > when doing ro-rfs its not FHS specified anyway. Lets not go with this >> > patch. >> >> Agreed. > > This isn't quite so simple as "agreed". Are we saying that we want to > rework volatiles handling after feature freeze? > > My view on this is that yes, we do need to do something about it, but > right now during stabilisation is not the right time. Particularly when > the patches proposed aren't even tested with sysvinit. > > So I'm interested in patches which make things work better without > making fundamental changes now. We can look at changing volatiles with a > properly thought out plan in the next development cycle. > > Making the systemd configuration match the rest of the default system > setup would seem to be sensible. We should make it possible for others > to override that if their setup isn't volatile. I am saying we should then test the patch (from Khem) and see if it is valid for merge. Khem being quite active contributor I am sure will be willing to help to fix any issue for merging (and regression, if any). I think having the volatile support working is very important and as we are not releasing tomorrow ... -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] directfb: Allow native builds of directfb 1.7.6
On Tue, Mar 10, 2015 at 3:04 PM, Florian Boor wrote: > From: Florian Boor > > Required by some DirectFB applications like dfbsee. > > Signed-off-by: Florian Boor > --- > meta/recipes-graphics/directfb/directfb_1.7.6.bb | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/meta/recipes-graphics/directfb/directfb_1.7.6.bb > b/meta/recipes-graphics/directfb/directfb_1.7.6.bb > index d25d987..7acb7e6 100644 > --- a/meta/recipes-graphics/directfb/directfb_1.7.6.bb > +++ b/meta/recipes-graphics/directfb/directfb_1.7.6.bb > @@ -19,3 +19,17 @@ LEAD_SONAME = "libdirectfb-1.7.so.0" > > SRC_URI[md5sum] = "8a7bb06b3f58599b230b4cf314004512" > SRC_URI[sha256sum] = > "44f32bacfb842ea234599532f8481fe41b5bd2310d2bd101508eb3a5df26c9e1" > + > +BBCLASSEXTEND = "native" > +DEPENDS_class-native = "jpeg-native libpng-native" Are you sure that excluding tslib-native from DEPENDS works? Since -lts is hardcoded in LDFLAGS (see directfb.inc) the linker won't run unless libts.so is found in sysroot (regardless of whether or not you configure with "--with-inputdrivers=none"). That being said, I don't know if -lts really needs to be hardcoded in LDFLAGS, it's been there since directfb was first imported into oe-core, with no explanation of comment. > +EXTRA_OECONF_class-native = "\ > + --enable-freetype=no \ > + --disable-zlib \ > + --with-gfxdrivers=none \ > + --disable-sdl \ > + --disable-vnc \ > + --disable-x11 \ > + --disable-imlib2 \ > + --disable-mesa \ > + --with-inputdrivers=none \ > +" > -- > 1.7.10.4 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] linux-yocto-rt: removed duplicated line
Seemed that the recipe contained redundant information.
Signed-off-by: Alexandru.Vaduva
---
meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
index 7dbf82c..bcfd754 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
@@ -23,5 +23,4 @@ COMPATIBLE_MACHINE =
"(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
features/taskstats/taskstats.scc"
KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
-KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] devshell: allow the starting directory to be overridden
Some people like to have the devshell start in ${B} instead of ${S}, so allow
this to be overridden.
Signed-off-by: Ross Burton
---
meta/classes/devshell.bbclass |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/devshell.bbclass b/meta/classes/devshell.bbclass
index 41164a3..8ae3dc3 100644
--- a/meta/classes/devshell.bbclass
+++ b/meta/classes/devshell.bbclass
@@ -17,7 +17,8 @@ python do_devshell () {
addtask devshell after do_patch
-do_devshell[dirs] = "${S}"
+DEVSHELL_STARTDIR ?= "${S}"
+do_devshell[dirs] = "${DEVSHELL_STARTDIR}"
do_devshell[nostamp] = "1"
# devshell and fakeroot/pseudo need careful handling since only the final
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dizzy] [PATCH 1/1] python: Add support for aarch64 for ctypes module
Tudor, I don't think aarch64 was supported in dizzy. If I find examples where it's support has been accept then I will consider letting this in. - Armin On 03/09/2015 05:24 PM, Tudor Florea wrote: Ping. -Original Message- From: Tudor Florea [mailto:tudor.flo...@enea.com] Sent: Wednesday, March 04, 2015 17:04 To: openembedded-core@lists.openembedded.org Cc: Tudor Florea Subject: [dizzy] [PATCH 1/1] python: Add support for aarch64 for ctypes module Python have its own version of libffi used for ctypes module. libffi 3.0.10 contained in original source of Python-2.7.3 does not have support for aarch64 architecture. This is patch is backport support for aarch64 from libffi 3.1 --- .../python/python/ctypes-libffi-aarch64.patch | 22 + .../python/python/libffi-aarch64.patch | 1608 meta/recipes-devtools/python/python_2.7.3.bb |2 + 3 files changed, 1632 insertions(+) create mode 100644 meta/recipes-devtools/python/python/ctypes-libffi- aarch64.patch create mode 100644 meta/recipes-devtools/python/python/libffi- aarch64.patch diff --git a/meta/recipes-devtools/python/python/ctypes-libffi- aarch64.patch b/meta/recipes-devtools/python/python/ctypes-libffi- aarch64.patch new file mode 100644 index 000..7349c7b --- /dev/null +++ b/meta/recipes-devtools/python/python/ctypes-libffi-aarch64.patch @@ -0,0 +1,22 @@ +Add missing fficonfig.py bits for aarch64 + +# HG changeset patch +# User Andreas Schwab +# Date 1367276434 -7200 +# Node ID 05e8999a3901b4853e60d6701510e9b3dd54a7f3 +# Parent 84cef4f1999ad9e362694cdac2f65f0981e3d5d0 + +Upstream-Status: Backport +Signed-off-by: Tudor Florea + +diff -r 84cef4f1999a -r 05e8999a3901 Modules/_ctypes/libffi/fficonfig.py.in +--- a/Modules/_ctypes/libffi/fficonfig.py.in Mon Apr 29 16:09:39 2013 - 0400 b/Modules/_ctypes/libffi/fficonfig.py.in Tue Apr 30 01:00:34 2013 +0200 +@@ -28,6 +28,7 @@ + 'PA': ['src/pa/linux.S', 'src/pa/ffi.c'], + 'PA_LINUX': ['src/pa/linux.S', 'src/pa/ffi.c'], + 'PA_HPUX': ['src/pa/hpux32.S', 'src/pa/ffi.c'], ++'AARCH64' : ['src/aarch64/ffi.c', 'src/aarch64/sysv.S'], + } + + ffi_sources += ffi_platforms['@TARGET@'] diff --git a/meta/recipes-devtools/python/python/libffi-aarch64.patch b/meta/recipes-devtools/python/python/libffi-aarch64.patch new file mode 100644 index 000..5581922 --- /dev/null +++ b/meta/recipes-devtools/python/python/libffi-aarch64.patch @@ -0,0 +1,1608 @@ +Add support for aarch64 for ctypes module + +Python have its own version of libffi used for ctypes module. +libffi 3.0.10 contained in original source of Python-2.7.3 does not have +support for aarch64 architecture. +This is patch is backport support for aarch64 from libffi 3.1 + +Upstream-Status: Backport +Signed-off-by: Tudor Florea + +diff -ruN Python-2.7.3.orig/Modules/_ctypes/libffi/configure.ac Python- 2.7.3/Modules/_ctypes/libffi/configure.ac +--- Python-2.7.3.orig/Modules/_ctypes/libffi/configure.ac 2015-02-27 23:15:16.118393178 +0100 Python-2.7.3/Modules/_ctypes/libffi/configure.ac 2015-02-27 23:51:03.351556903 +0100 +@@ -44,6 +44,10 @@ + + TARGETDIR="unknown" + case "$host" in ++ aarch64*-*-*) ++ TARGET=AARCH64; TARGETDIR=aarch64 ++ ;; ++ + alpha*-*-*) + TARGET=ALPHA; TARGETDIR=alpha; + # Support 128-bit long double, changeable via command-line switch. +@@ -195,6 +199,7 @@ + AM_CONDITIONAL(POWERPC_AIX, test x$TARGET = xPOWERPC_AIX) + AM_CONDITIONAL(POWERPC_DARWIN, test x$TARGET = xPOWERPC_DARWIN) + AM_CONDITIONAL(POWERPC_FREEBSD, test x$TARGET = xPOWERPC_FREEBSD) ++AM_CONDITIONAL(AARCH64, test x$TARGET = xAARCH64) + AM_CONDITIONAL(ARM, test x$TARGET = xARM) + AM_CONDITIONAL(AVR32, test x$TARGET = xAVR32) + AM_CONDITIONAL(LIBFFI_CRIS, test x$TARGET = xLIBFFI_CRIS) +diff -ruN Python-2.7.3.orig/Modules/_ctypes/libffi/src/aarch64/ffi.c Python-2.7.3/Modules/_ctypes/libffi/src/aarch64/ffi.c +--- Python-2.7.3.orig/Modules/_ctypes/libffi/src/aarch64/ffi.c 1970- 01-01 01:00:00.0 +0100 Python-2.7.3/Modules/_ctypes/libffi/src/aarch64/ffi.c 2014-04-25 19:45:13.0 +0200 +@@ -0,0 +1,1168 @@ ++/* Copyright (c) 2009, 2010, 2011, 2012 ARM Ltd. ++ ++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 NONINFRINGEME
Re: [OE-core] [PATCH] systemd: Instruct the journal to always be volatile
> On Mar 12, 2015, at 1:04 AM, Richard Purdie > wrote: > > On Thu, 2015-03-12 at 04:18 -0300, Otavio Salvador wrote: >> On Thu, Mar 12, 2015 at 12:09 AM, Khem Raj wrote: >>> On Mar 11, 2015, at 2:28 PM, Randy Witt wrote: When the storage mode for the journal is "auto" if /var/log/journal exists then the journal will flush to /var/log/journal assuming that /var/log/journal is persistent. However /var/log -> /var/volatile/log in poky, so even though /var/log/journal exists, it is still volatile. Since this can cause ordering issues due to /var/volatile needing to be mounted before the journal actually writes to it, just specify that the journal should always be volatile and never try to write to "persistent" storage. The journal will exist in /run/log/journal only. This also disables the "After" of the journal on var-volatile.mount since the ordering is no longer necessary when the journal is only stored in /run/log/journal. [Yocto #7388] >>> >>> >>> This is not right. What if I want persistent logs.? the options is just >>> gone. Both cases should work. /var/volatile should only be used >>> when doing ro-rfs its not FHS specified anyway. Lets not go with this patch. >> >> Agreed. > > This isn't quite so simple as "agreed". Are we saying that we want to > rework volatiles handling after feature freeze? > > My view on this is that yes, we do need to do something about it, but > right now during stabilisation is not the right time. Particularly when > the patches proposed aren't even tested with sysvinit. I usually send out patches early to take advantage of some community testing especially Yocto auto builders, Since not everyone has hefty machines to do all kind of builds for such changes. Meanwhile, keep doing it in serial order. > > So I'm interested in patches which make things work better without > making fundamental changes now. We can look at changing volatiles with a > properly thought out plan in the next development cycle. Whatever is decided I have already said thats fine, so lets just stop this thread here. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: fix /var/log/journal ownership
On 12/03/2015 6:21 PM, Khem Raj wrote:
On Mar 12, 2015, at 12:14 AM, ChenQi wrote:
On 03/10/2015 11:25 AM, Jonathan Liu wrote:
The ownership needs to be explicitly set otherwise it inherits the user
and group id of the build user.
Signed-off-by: Jonathan Liu
---
meta/recipes-core/systemd/systemd_219.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index 24486f1..6a4f4e8 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -147,6 +147,8 @@ do_install() {
sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd%
${D}${sysconfdir}/init.d/systemd-udevd
fi
+ chown root:root ${D}/${localstatedir}/log/journal
+
# Delete journal README, as log can be symlinked inside volatile.
rm -f ${D}/${localstatedir}/log/README
I think it should be root:systemd-journal.
What do you think?
And this patch would also fix the following bug.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7293
/var/log is symlinked (its not a copy-bind) into /var/volatile/log and
/var/volatile is mounted as tmpfs on runtime as of now
so how is this patch helping out with anything ?
It fixes uid/gid of build user leaking into the filesystem image even if
the directory is hidden at runtime by tmpfs being mounted at /var/volatile.
I was considering removing /var/log/journal (actually
/var/volatile/log/journal) from the rootfs but it would be a behavior
change.
journald.conf by default tests for the presence of the /var/log/journal
directory and if it exists it will write there (instead of
/run/log/journal) assuming it is persistent.
An OpenEmbedded user could try making the journal persistent by removing
the /var/volatile tmpfs entry from /etc/fstab (I remember seeing this
mentioned somewhere on the web). This would make /var/volatile persistent...
I opted to keep /var/log/journal but fix the uid/gid to avoid surprises.
You're right though, it should be root:systemd-journal.
Regards,
Jonathan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] systemd: fix /var/log/journal ownership
The ownership needs to be explicitly set otherwise it inherits the user
and group id of the build user.
Signed-off-by: Jonathan Liu
---
meta/recipes-core/systemd/systemd_219.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index d5eed08..41f6b2c 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -153,6 +153,8 @@ do_install() {
sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd%
${D}${sysconfdir}/init.d/systemd-udevd
fi
+ chown root:systemd-journal ${D}/${localstatedir}/log/journal
+
# Delete journal README, as log can be symlinked inside volatile.
rm -f ${D}/${localstatedir}/log/README
--
2.3.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dizzy][PATCH v2] systemd: fix /var/log/journal ownership
The ownership needs to be explicitly set otherwise it inherits the user
and group id of the build user.
Signed-off-by: Jonathan Liu
---
meta/recipes-core/systemd/systemd_216.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_216.bb
b/meta/recipes-core/systemd/systemd_216.bb
index 3852841..1eb4019 100644
--- a/meta/recipes-core/systemd/systemd_216.bb
+++ b/meta/recipes-core/systemd/systemd_216.bb
@@ -136,6 +136,8 @@ do_install() {
sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd%
${D}${sysconfdir}/init.d/systemd-udevd
fi
+ chown root:systemd-journal ${D}/${localstatedir}/log/journal
+
# Delete journal README, as log can be symlinked inside volatile.
rm -f ${D}/${localstatedir}/log/README
--
2.3.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [daisy][PATCH v2] systemd: fix /var/log/journal ownership
The ownership needs to be explicitly set otherwise it inherits the user
and group id of the build user.
Signed-off-by: Jonathan Liu
---
meta/recipes-core/systemd/systemd_211.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_211.bb
b/meta/recipes-core/systemd/systemd_211.bb
index 567c323..98c4aca 100644
--- a/meta/recipes-core/systemd/systemd_211.bb
+++ b/meta/recipes-core/systemd/systemd_211.bb
@@ -124,6 +124,8 @@ do_install() {
sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd%
${D}${sysconfdir}/init.d/systemd-udevd
fi
+ chown root:systemd-journal ${D}/${localstatedir}/log/journal
+
# Delete journal README, as log can be symlinked inside volatile.
rm -f ${D}/${localstatedir}/log/README
}
--
2.3.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how many ways to delete/de-activate a recipe's task?
On Wed, 2015-03-11 at 12:22 -0500, Mark Hatle wrote: > On 3/11/15 11:30 AM, Robert P. J. Day wrote: > > > > i recall that richard purdie might have explained this once but i > > have no idea where that post is and i need to add something to it, > > anyway ... how many ways are there to "delete" a task from a recipe, > > and what are the differences? > > > > so far, i've seen: > > > > 1) bitbake supports a "deltask" directive > > The task and all it's dependencies go away. So anything dependent on it and > the > things it depends on, are no longer dependent. > > > 2) you can use the [noexec] task flag > > The task and it's dependencies remain, but nothing is executed. > > > 3) i've also seen redefining the task with a no-op ":" command > > The task is executed and does nothing. (I believe this dumps a stamp file and > the noexec does not.. but I may be wrong.) What Mark said. 3) is the old way of doing 2), we added 2) to make it more efficient since there is no task execution overhead (which at one point was measurable, it may be less so now). Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] e2fsprogs: CVE-2015-0247
Fixes a heap buffer overflow in lib/ext2fs/openfs.c which allows
a trivial arbitrary memory write under certain conditions.
References
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=f66e6ce4
http://www.ocert.org/advisories/ocert-2015-002.html
Signed-off-by: Sona Sarmadi
---
.../e2fsprogs/e2fsprogs/CVE-2015-0247.patch| 58 ++
.../recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 1 +
2 files changed, 59 insertions(+)
create mode 100644
meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2015-0247.patch
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2015-0247.patch
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2015-0247.patch
new file mode 100644
index 000..4de67c9
--- /dev/null
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2015-0247.patch
@@ -0,0 +1,58 @@
+From f66e6ce4446738c2c7f43d41988a3eb73347e2f5 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o
+Date: Sat, 9 Aug 2014 12:24:54 -0400
+Subject: libext2fs: avoid buffer overflow if s_first_meta_bg is too big
+
+If s_first_meta_bg is greater than the of number block group
+descriptor blocks, then reading or writing the block group descriptors
+will end up overruning the memory buffer allocated for the
+descriptors. Fix this by limiting first_meta_bg to no more than
+fs->desc_blocks. This doesn't correct the bad s_first_meta_bg value,
+but it avoids causing the e2fsprogs userspace programs from
+potentially crashing.
+
+Fixes CVE-2015-0247
+Upstream-Status: Backport
+
+Signed-off-by: Theodore Ts'o
+Signed-off-by: Sona Sarmadi
+
+diff --git a/lib/ext2fs/closefs.c b/lib/ext2fs/closefs.c
+index 4599eef..1f99113 100644
+--- a/lib/ext2fs/closefs.c
b/lib/ext2fs/closefs.c
+@@ -344,9 +344,11 @@ errcode_t ext2fs_flush2(ext2_filsys fs, int flags)
+* superblocks and group descriptors.
+*/
+ group_ptr = (char *) group_shadow;
+- if (fs->super->s_feature_incompat & EXT2_FEATURE_INCOMPAT_META_BG)
++ if (fs->super->s_feature_incompat & EXT2_FEATURE_INCOMPAT_META_BG) {
+ old_desc_blocks = fs->super->s_first_meta_bg;
+- else
++ if (old_desc_blocks > fs->super->s_first_meta_bg)
++ old_desc_blocks = fs->desc_blocks;
++ } else
+ old_desc_blocks = fs->desc_blocks;
+
+ ext2fs_numeric_progress_init(fs, &progress, NULL,
+diff --git a/lib/ext2fs/openfs.c b/lib/ext2fs/openfs.c
+index a1a3517..ba501e6 100644
+--- a/lib/ext2fs/openfs.c
b/lib/ext2fs/openfs.c
+@@ -378,9 +378,11 @@ errcode_t ext2fs_open2(const char *name, const char
*io_options,
+ #ifdef WORDS_BIGENDIAN
+ groups_per_block = EXT2_DESC_PER_BLOCK(fs->super);
+ #endif
+- if (fs->super->s_feature_incompat & EXT2_FEATURE_INCOMPAT_META_BG)
++ if (fs->super->s_feature_incompat & EXT2_FEATURE_INCOMPAT_META_BG) {
+ first_meta_bg = fs->super->s_first_meta_bg;
+- else
++ if (first_meta_bg > fs->desc_blocks)
++ first_meta_bg = fs->desc_blocks;
++ } else
+ first_meta_bg = fs->desc_blocks;
+ if (first_meta_bg) {
+ retval = io_channel_read_blk(fs->io, group_block +
+--
+cgit v0.10.2
+
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
index 656793f..87e06e3 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
@@ -20,6 +20,7 @@ SRC_URI += "file://acinclude.m4 \
file://0001-e2fsprogs-fix-cross-compilation-problem.patch \
file://misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch
\
file://cache_inode.patch \
+file://CVE-2015-0247.patch \
"
SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] directfb: Allow native builds of directfb 1.7.6
Hi Florian, On Wed, Mar 11, 2015 at 2:24 AM, Florian Boor wrote: > Hi Arndre, > > On 10.03.2015 23:32, Andre McCurdy wrote: >> Are you sure that excluding tslib-native from DEPENDS works? Since >> -lts is hardcoded in LDFLAGS (see directfb.inc) the linker won't run >> unless libts.so is found in sysroot (regardless of whether or not you >> configure with "--with-inputdrivers=none"). That being said, I don't >> know if -lts really needs to be hardcoded in LDFLAGS, it's been there >> since directfb was first imported into oe-core, with no explanation of >> comment. > > yes it works - tested it and made sure that there was no native libts around > from a previous build. That's a bit mysterious. It does fail for me. I wonder if your build is somehow finding a libts.so from the host system? > But you are right, this hardcoded -lts in LDFLAGS looks strange. I can take a > look at this later since I need to build and test this anyway. Good, I think removing the hardcoded -lts from LDFLAGS is going to be the right approach. > > Greetings > > Florian > > -- > The dream of yesterday Florian Boor > is the hope of todayTel: +49 271-771091-15 > and the reality of tomorrow.Fax: +49 271-771091-19 > [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de > http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] combining "_append" with "+=" (was: proper "style" for VAR_append_override?)
On Sunday 08 March 2015 04:45:14 Robert P. J. Day wrote:
> On Sat, 7 Mar 2015, Paul Eggleton wrote:
> > On Saturday 07 March 2015 09:43:34 Robert P. J. Day wrote:
> > > more nitpickery, but i've noticed a couple different ways in the OE
> > >
> > > code base and documentation for conditionally appending based on an
> > > override, and it might just be that i'm confused about the underlying
> > > mechanics of the append operators.
> > >
> > > first, there's this from qemu.inc:
> > > KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
> > >
> > > i've always read that as, "if override of linux-yocto package is in
> > > effect, then add this feature to KERNEL_FEATURES using the "append"
> > > operator, which will leave the appending to the end and, in addition,
> > > *requires* that we explicitly have that leading space given that we're
> > > using _append.
> > >
> > > it's also my understanding that i can have multiple assignments like
> > >
> > > that (possibly based on different overrides), and they will all be
> > > processed properly and finally appended to (in this case)
> > > KERNEL_FEATURES. so far, so good?
> > >
> > > but if i check the YP ref manual, i see documentation like this:
> > > ref-variables.xml: KERNEL_FEATURES_append_cedartrail +=
> > > "bsp/cedartrail/cedartrail-pvr-merge.scc" ref-variables.xml:
> > >
> > > KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc" ref-variables.xml:
> > > KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
> > >
> > > which looks a bit weird -- combining "_append" with "+=" (and even
> > > inconsistently adding that leading space).
> > >
> > > is there some difference between the above approaches i've never
> > >
> > > understood? is there a preferred style?
> >
> > IMO, '..._append +=' shouldn't be used. It might be assumed that the
> > += accomplishes more than just adding a leading space, which it
> > doesn't. It's much simpler to just include the leading space in the
> > value.
>
> i agree, and there's a ton of that stuff under the meta-yocto layer
> in scripts/lib/bsp/substrate/target/arch (obviously directly related
> to the very example i pulled out of the reference manual):
>
> $ grep -r "_append.*+=" *
> i386/recipes-kernel/linux/linux-yocto-tiny_3.14.bbappend:KERNEL_FEATURES_app
> end_{{=machine}} += " cfg/smp.scc"
> i386/recipes-kernel/linux/linux-yocto_3.17.bbappend:KERNEL_FEATURES_append_
> {{=machine}} += " cfg/smp.scc"
> i386/recipes-kernel/linux/linux-yocto-dev.bbappend:KERNEL_FEATURES_append_{
> {=machine}} += " cfg/smp.scc"
> i386/recipes-kernel/linux/linux-yocto_3.14.bbappend:KERNEL_FEATURES_append_
> {{=machine}} += " cfg/smp.scc"
> mips/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend:KERNEL_FEATURES_appe
> nd_{{=machine}} += " cfg/smp.scc"
> mips/recipes-kernel/linux/linux-yocto-tiny_3.10.bbappend:KERNEL_FEATURES_ap
> pend_{{=machine}} += " cfg/smp.scc"
> mips/recipes-kernel/linux/linux-yocto-tiny_3.17.bbappend:KERNEL_FEATURES_ap
> pend_{{=machine}} += " cfg/smp.scc"
> mips/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend:KERNEL_FEATURES_appe
> nd_{{=machine}} += " cfg/smp.scc"
> mips/recipes-kernel/linux/linux-yocto_3.10.bbappend:KERNEL_FEATURES_append_
> {{=machine}} += " cfg/smp.scc" ... snip lots more of exactly the same stuff
> ...
> $
>
> it's obviously not hard to grep for the string "_append.*+=" to see
> where stuff like this is happening -- i'll let someone else decide
> what to do about it; most of it is in the meta-yocto layer under
> scripts/.
I think pretty much all of those should get fixed. They've probably fallen
under the radar since they aren't strictly part of the metadata, but they are
important as these are the templates from which new BSPs are created from
yocto-bsp.
> final note: i realize that a lot of my nitpickery is just that --
> nitpickery -- but i'm trying to prevent possibilities for confusion
> for newer readers and users. in cases like this, if the (bitbake)
> manual explains that there's one way to do appending (+=) and a second
> way to do appending (_append), and readers think they understand the
> difference, then it's definitely setting them up for confusion to see
> both constructs being used at the same time on the same line. hence,
> the relentless pedantry.
Right, and we certainly do appreciate all of your input, I hope we don't seem
too grumpy or dismissive in response ;) Our recipes should be the ultimate
example in how to do things properly and we should try to make sure that they
are if at all possible.
> p.s. a small number of examples of the same thing under OE layer:
>
> $ grep -r "_append_.*+=" *
> recipes-core/libxml/libxml2.inc:RDEPENDS_${PN}-ptest_append_libc-glibc +=
> "glibc-gconv-ebcdic-us glibc-gconv-ibm1141"
> recipes-devtools/unfs3/unfs3_0.9.22.r490.bb:DEPENDS_append_class-nativesdk
> += "flex-nativesdk"
> recipes-support/gnutls/gnutls.inc:LDFLAGS_append_libc-uclibc += " -pthread"
> $
>
> in cases
Re: [OE-core] [PATCH] meta/lib/oe/package.py: Fix for bug 7428
Please change the commit summary to describe what the problem/fix is, instead of just linking to the bug number. Then at the end of the commit message, refer to the bug like [YOCTO #7428]. Ross On 12 March 2015 at 07:57, Fabrice Coulon wrote: > This fix solves the problem with the ownership of files in packages. > The do_install task was producing correct and expected output but when > the files were being put in, e.g. a rpm package, the ownership could > be different than that in the do_install task. > > Signed-off-by: Peter Kjellerstedt > Signed-off-by: Fabrice Coulon > --- > meta/lib/oe/package.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py > index 7c728fc..8bc56c6 100644 > --- a/meta/lib/oe/package.py > +++ b/meta/lib/oe/package.py > @@ -31,7 +31,7 @@ def runstrip(arg): > extraflags = "--remove-section=.comment --remove-section=.note" > > # Use mv to break hardlinks > -stripcmd = "'%s' %s '%s' -o '%s.tmp' && mv '%s.tmp' '%s'" % (strip, > extraflags, file, file, file, file) > +stripcmd = "'%s' %s '%s' -o '%s.tmp' && chown --reference='%s' > '%s.tmp' && mv '%s.tmp' '%s'" % (strip, extraflags, file, file, file, file, > file, file) > bb.debug(1, "runstrip: %s" % stripcmd) > > ret = subprocess.call(stripcmd, shell=True) > -- > 1.9.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] tar: set acpaths to avoid "Argument list too long" error
On 12 March 2015 at 06:14, Robert Yang wrote:
> +acpaths = "-I ./m4"
>
Why does this only happen on tar? Why is it safe to pass just -I ./m4 when
the detected list that you're overriding is effectively -I ./m4 -I ./tests?
Would it be better to just make all include paths relative to ${S} when
generating the acpaths?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] tar: set acpaths to avoid "Argument list too long" error
On Thu, 2015-03-12 at 12:16 +, Burton, Ross wrote:
> On 12 March 2015 at 06:14, Robert Yang
> wrote:
> +acpaths = "-I ./m4"
>
> Why does this only happen on tar? Why is it safe to pass just -I ./m4
> when the detected list that you're overriding is effectively -I ./m4
> -I ./tests?
>
> Would it be better to just make all include paths relative to ${S}
> when generating the acpaths?
We tried that. Subconfigures break:
http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/autotools.bbclass?id=3c58f92d46e32c40b80575f14e0f6f66c9920c66
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OE Changelog since 2015-03-01 until 2015-03-08
Changelog since 2015-03-01 until 2015-03-08. 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-atmel: https://github.com/linux4sam/meta-atmel.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: Changelog for openembedded-core: Bernhard Reutner-Fischer (1): scripts/runqemu: clarify help text Bruce Ashfield (4): linux-yocto: fix qemux86-64 config warning kernel-yocto: inhibit BSP description warnings for custom linux-yocto kernel linux-yocto/3.14: OcteonIII support kern-tools: improve patch application performance Jian Liu (1): man: fix bugs of makewhatis script Jonathan Liu (1): qt4: add patch for BMP denial-of-service vulnerability Peter Urbanec (1): glibc: Fix check for -Os. Richard Purdie (2): taglib: Fix cmake floating dependency on boost build-appliance-image: Update to master head revision Ross Burton (4): security_flags: remove PIE flags from flex and gstreamer1.0-plugins-bad gst-player: port to GTK+ 2 gstreamer1.0-plugins-bad: disable Yadif on X32 systemd: fix tmpfiles error on images without PAM Changelog for meta-openembedded: Andreas Müller (1): qt-creator: avoid conflicts with meta-qt5's qt5-creator Armin Kuster (2): edac-utils: Add new package mcelog: update to latest Ash Charles (1): xfce4-session: Remove unneeded pkg_postinst Baptiste DURAND (1): minidlna: Fix package and bump to version 1.1.4 Bian Naimeng (1): xbitmaps: fix build warning. Daniel Markus (1): socorro-syms: Add Breakpad symbol generation adapted for Socorro Eduardo Silva (1): Monkey: new v1.5.6 release. Florian Boor (1): fltk: Replace use of freetype-config with pkg-config Drop blacklist entry Joe MacDonald (2): nis: integrate latest stable yp-tools and ypbind nis: blacklist updated yp tools Khem Raj (4): collectd: Backport fix build with newer gcc v4l-utils: RPROVIDE media-ctl lirc: Add recipe for 0.9.2 lirc: Recommend to have lirc-plugins at runtime Koen Kooi (1): mozjs 17.0.0: fix aarch64 and 64k page builds, generic cleanups Mario Domenech Goulart (1): python-urllib3: add recipe for version 1.10.1 Martin Jansa (6): linux-yocto-tiny-kexecboot: remove 3.10, 3.17 and add 3.19 vim: fix up for /bin/vi e-wm: upgrade to 0.19.3 ypbind-mt: fix typo in PNBLACKLIST to really blacklist it mplayer2: set REQUIRED_DISTRO_FEATURES and LICENSE_FLAGS vboxguestdrivers: import recipe from meta-luneos Raphael Silva (1): fio: fix do_compile error Sven Ebenfeld (4): claws-mail: Fix SRC_URI pxaregs: Add source file and fix SRC_URI lightmediascanner: Fix SRC_URI serial-utils: Fix SRC_URI Yevhen Kyriukha (1): rabbitmq-c: update to v0.6.0. mike.looijm...@topic.nl (1): opencv: Upg
Re: [OE-core] [PATCH V2 0/4] systemd and dbus split into packages
Ping
On Seg, 2015-03-09 at 18:10 -0300, Bruno Bottazzini wrote:
> Differences from v1:
>
> dbus: Adding change that Andreas Oberritter recommended.
> -Setting RRECOMMENDS_${PN}_class-native instead RPROVIDES
> dbus-native-tools-native.
>
> systemd: Adding change that Anders Darander and Khem Raj recommended
> -Modifying PACKAGECONFIG as requested to use it with bbutils.
>
> systemd: Adding change that Khem Raj requested:
> -Porting patches that was used on the release of the 219 stable version
> instead of changing the repository.
>
>
> ---
> In this patchset we include the following:
>
> 1- dbus: split tools package
>Most tools are not required if one is launching a simple daemon.
>So, we split it into two packages dbus and dbus-tools which the user
>will be able to exclude it from the image if he wants to.
>
> 2- systemd: verify if files test-udev and systemd-journal-flush exists
>If the user put --disable-tests on EXTRA_OECONF for systemd, some files
> will
>not be created and systemd do_install phase
>will fail.
>This patch will give this flexibility for the user
>
> 3- systemd: split modules into packages
>Since systemd repo grows with more and more tools, the recipe will provide
>a customizable layer and he will be able to choose what he wants to ship
>to the final image.
>He will be able to save space and exclude unwanted packages from the
>final image.
>
> 4- systemd: add patches from systemd 219 - stable
>Adding patches that fix bugs for 219 version.
>This will get the same consistency of the stable systemd 219 version.
>
>
> Bruno Bottazzini (3):
> systemd: verify if files test-udev and systemd-journal-flush exists
> systemd: split modules into packages
> systemd: v219 with stable fixes
>
> Gustavo Sverzut Barbieri (1):
> dbus: split tools package.
>
> Bruno Bottazzini (3):
> systemd: verify if files test-udev and systemd-journal-flush exists
> systemd: split modules into packages
> systemd: v219 with stable fixes
>
> Gustavo Sverzut Barbieri (1):
> dbus: split tools package.
>
> meta/recipes-core/dbus/dbus.inc|9 +-
> ...remote-fix-certificate-status-memory-leak.patch | 31 +
> ...ournal-remote-fix-client_cert-memory-leak.patch | 35 +
> ...0003-tmpfiles-Fix-parse_acl-error-message.patch | 28 +
> ...-test-utf8-fix-utf16-tests-on-BE-machines.patch | 26 +
> ...iles-avoid-creating-duplicate-acl-entries.patch | 131 +++
> .../0006-shared-time-util-fix-gcc5-warning.patch | 32 +
> ...time-test-infinity-parsing-in-nanoseconds.patch | 36 +
> .../0008-bootchart-fix-default-init-path.patch | 44 +
> ...emctl-bump-NOFILE-only-for-systemctl_main.patch | 44 +
> ...0-Make-root-s-home-directory-configurable.patch | 89 +-
> ...-util-avoid-freeing-uninitialized-pointer.patch | 37 +
> ...11-bootchart-svg-fix-checking-of-list-end.patch | 28 +
> ...md-add-getrandom-syscall-numbers-for-MIPS.patch | 38 +
> ...aker-dependencies-between-mount-and-devic.patch | 33 +
> ...topping-due-to-BindsTo-log-which-unit-cau.patch | 43 +
> ...grade-message-about-sysctl-overrides-to-d.patch | 30 +
> ...l-add-some-hints-how-to-override-settings.patch | 39 +
> .../0017-core-rework-device-state-logic.patch | 912
> .../0018-core-fix-return-value-on-OOM.patch| 26 +
> ...e-x-machine-unix-prefix-for-the-container.patch | 33 +
> ...0-shared-AFS-is-also-a-network-filesystem.patch | 25 +
> ...downgrade-unit-type-not-supported-message.patch | 31 +
> ...ournal-remote-fix-saving-of-binary-fields.patch | 97 ++
> ...ix-Inappropriate-ioctl-for-device-on-ext4.patch | 37 +
> ...eplace-VLA-with-alloca-to-make-llvm-happy.patch | 53 +
> ...ietly-ignore-ACLs-on-unsupported-filesyst.patch | 84 ++
> ...-assume-ac-when-sys-class-power_supply-is.patch | 30 +
> meta/recipes-core/systemd/systemd_219.bb |
> +---
> 29 files changed, 3006 insertions(+), 186 deletions(-)
> create mode 100644
> meta/recipes-core/systemd/systemd/0001-journal-remote-fix-certificate-status-memory-leak.patch
> create mode 100644
> meta/recipes-core/systemd/systemd/0002-journal-remote-fix-client_cert-memory-leak.patch
> create mode 100644
> meta/recipes-core/systemd/systemd/0003-tmpfiles-Fix-parse_acl-error-message.patch
> create mode 100644
> meta/recipes-core/systemd/systemd/0004-test-utf8-fix-utf16-tests-on-BE-machines.patch
> create mode 100644
> meta/recipes-core/systemd/systemd/0005-tmpfiles-avoid-creating-duplicate-acl-entries.patch
> create mode 100644
> meta/recipes-core/systemd/systemd/0006-shared-time-util-fix-gcc5-warning.patch
> create mode 100644
> meta/recipes-core/systemd/systemd/0007-test-time-test-infinity-parsing-in-nanoseconds.patch
> create mode 100644
> meta/recipes-core/systemd/systemd/0008-bootchart-fix-default-init-p
[OE-core] meta-gir issues and maintenance
Hi Tomas, all, I was trying to use meta-gir in Dizzy release and found out that last commit in this layer is 16 months ago and many .bbappends no longer match with their recipes. Was this layer superseded by something else or you just didn't have time to update it for newer Yocto releases? Even the base meta-gir layer have issue with g-ir-core recipe which is currently failing with Dizzy release (it seems to be working fine with Dylan): $ cat /OE/build/oe-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/g-ir-core/1.34.2-r0/temp/log.do_compile.660 DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common'] DEBUG: Executing shell function do_compile NOTE: make -j 9 [ -d gir ] || /bin/mkdir -p gir ; \ sed \ -e s,%CAIRO_SHARED_LIBRARY%,libcairo-gobject.so.2, \ -e s,%CAIRO_GIR_PACKAGE%,cairo-gobject, \ < /OE/build/oe-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/g-ir-core/1.34.2-r0/gobject-introspection-1.34.2/gir/cairo-1.0.gir.in > gir/cairo-1.0.gir.tmp && mv gir/cairo-1.0.gir.tmp gir/cairo-1.0.gir make all-recursive make[1]: Entering directory '/OE/build/oe-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/g-ir-core/1.34.2-r0/build' Making all in . make[2]: Entering directory '/OE/build/oe-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/g-ir-core/1.34.2-r0/build' g-ir-scanner --namespace=GLib --nsversion=2.0 --libtool="./arm-oe-linux-gnueabi-libtool" --pkg=glib-2.0--library=glib-2.0 --library=gobject-2.0 --external-library --reparse-validate --identifier-prefix=G --symbol-prefix=g --symbol-prefix=glib --c-include="glib.h" -I/OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0 -I/OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/lib/glib-2.0/include -DGETTEXT_PACKAGE=Dummy -DGLIB_COMPILATION -D__G_I18N_LIB_H__ /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/lib/glib-2.0/include/glibconfig.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/giochannel.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gprintf.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gtestutils.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gversion.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/genviron.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gmacros.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gprimes.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/ghook.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gvariant.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/garray.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gmem.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gmappedfile.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gtrashstack.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gerror.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gnode.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gi18n-lib.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gkeyfile.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gregex.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gsequence.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/ggettext.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/goption.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gstringchunk.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gstring.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gscanner.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gdataset.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gpoll.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gdatetime.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gbase64.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/ghmac.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gurifuncs.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gslice.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gquark.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gmain.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/ghostutils.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gbytes.h /OE/build/oe-core/tmp-glibc/sysroots/qemuarm//usr/include/glib-2.0/glib/gmessages.h /OE/build/oe-core/tmp-glibc
[OE-core] [PATCH] meta/lib/oe/package.py: fix files ownership in packages
This fix solves the problem with the ownership of files in packages. The do_install task was producing correct and expected output but when the files were being put in, e.g. a rpm package, the ownership could be different than that in the do_install task. [YOCTO #7428] Signed-off-by: Peter Kjellerstedt Signed-off-by: Fabrice Coulon --- meta/lib/oe/package.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index 7c728fc..8bc56c6 100644 --- a/meta/lib/oe/package.py +++ b/meta/lib/oe/package.py @@ -31,7 +31,7 @@ def runstrip(arg): extraflags = "--remove-section=.comment --remove-section=.note" # Use mv to break hardlinks -stripcmd = "'%s' %s '%s' -o '%s.tmp' && mv '%s.tmp' '%s'" % (strip, extraflags, file, file, file, file) +stripcmd = "'%s' %s '%s' -o '%s.tmp' && chown --reference='%s' '%s.tmp' && mv '%s.tmp' '%s'" % (strip, extraflags, file, file, file, file, file, file) bb.debug(1, "runstrip: %s" % stripcmd) ret = subprocess.call(stripcmd, shell=True) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] remove unnecessary 'protocol=git' from SRC_URI
Update the following recipes by removing unnecessary 'protocol=git' from SRC_URI Maxin B. John (5): u-boot-fw-utils: remove unnecessary 'protocol=git' from SRC_URI u-boot-mkimage: remove unnecessary 'protocol=git' from SRC_URI systemd: remove unnecessary 'protocol=git' from SRC_URI mmc-utils: remove unnecessary 'protocol=git' from SRC_URI trace-cmd: remove unnecessary 'protocol=git' from SRC_URI meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb | 2 +- meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb | 2 +- meta/recipes-core/systemd/systemd_219.bb | 2 +- meta/recipes-devtools/mmc/mmc-utils_git.bb | 2 +- meta/recipes-kernel/trace-cmd/trace-cmd.inc| 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] systemd: remove unnecessary 'protocol=git' from SRC_URI
Signed-off-by: Maxin B. John
---
meta/recipes-core/systemd/systemd_219.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index d5eed08..e9b3c84 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -29,7 +29,7 @@ SRCREV = "a88abde72169ddc2df77df3fa5bed30725022253"
PV = "219+git${SRCPV}"
-SRC_URI =
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=git \
+SRC_URI = "git://anongit.freedesktop.org/systemd/systemd;branch=master \
file://0002-shared-missing.h-fall-back-to-insecure-getenv.patch \
file://0003-binfmt-Don-t-install-dependency-links-at-install-tim.patch \
file://0004-configure-Check-for-additional-features-that-uclibc-.patch \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] u-boot-fw-utils: remove unnecessary 'protocol=git' from SRC_URI
Signed-off-by: Maxin B. John
---
meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb
index 2b0550c..b310b0d 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb
@@ -11,7 +11,7 @@ SRCREV = "92fa7f53f1f3f03296f8ffb14bdf1baefab83368"
PV = "v2015.01+git${SRCPV}"
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git \
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master \
file://0001-tools-env-fix-build-error.patch"
S = "${WORKDIR}/git"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] u-boot-mkimage: remove unnecessary 'protocol=git' from SRC_URI
Signed-off-by: Maxin B. John
---
meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb
index 57989c7..076dff8 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb
@@ -12,7 +12,7 @@ SRCREV = "92fa7f53f1f3f03296f8ffb14bdf1baefab83368"
PV = "v2015.01+git${SRCPV}"
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
S = "${WORKDIR}/git"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] trace-cmd: remove unnecessary 'protocol=git' from SRC_URI
Signed-off-by: Maxin B. John
---
meta/recipes-kernel/trace-cmd/trace-cmd.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/trace-cmd/trace-cmd.inc
b/meta/recipes-kernel/trace-cmd/trace-cmd.inc
index feb56e1..87e4a9c 100644
--- a/meta/recipes-kernel/trace-cmd/trace-cmd.inc
+++ b/meta/recipes-kernel/trace-cmd/trace-cmd.inc
@@ -5,7 +5,7 @@ inherit pkgconfig
FILESEXTRAPATHS =. "${FILE_DIRNAME}/trace-cmd:"
-SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git;protocol=git;branch=trace-cmd-stable-v2.5
\
+SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git;branch=trace-cmd-stable-v2.5
\
file://blktrace-api-compatibility.patch \
"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] mmc-utils: remove unnecessary 'protocol=git' from SRC_URI
Signed-off-by: Maxin B. John
---
meta/recipes-devtools/mmc/mmc-utils_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/mmc/mmc-utils_git.bb
b/meta/recipes-devtools/mmc/mmc-utils_git.bb
index c54e351..bdb4fed 100644
--- a/meta/recipes-devtools/mmc/mmc-utils_git.bb
+++ b/meta/recipes-devtools/mmc/mmc-utils_git.bb
@@ -8,7 +8,7 @@ SRCREV = "f4eb241519f8d500ce6068a70d2389be39ac5189"
PV = "0.1"
-SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;protocol=git;branch=${BRANCH}
\
+SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${BRANCH}
\
file://0001-mmc.h-don-t-include-asm-generic-int-ll64.h.patch"
S = "${WORKDIR}/git"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] clang cross compiler for OE available in meta-clang
Hi All, Finally, clang/llvm is now in a working state as a cross compiler in meta-clang layer https://github.com/kraj/meta-clang Currently, It will build clang and stage it along with gcc cross compilers, default remains as it is. If you wish to compile an additional recipe using clang you will add following two entries per recipe TOOLCHAIN_pn- = "clang" DEPENDS_append_pn- = " clang-cross " to conf/clang.conf and it will start using clang for that component. Right now it only has one entry for ‘lzo’ :) I am hoping to have this list grow soon Right now, its only the cross compiler, which means compiler runtime is still same from gcc and binutils are used in same way Eventually, I will add compiler-rt and libc++ as well and also add cross-canadian builds of clang and make it cohabit in SDK along with gcc. If you would like to help trying/porting recipes to use clang/llvm or improve the layer, please lend your hand Thanks for your time -Khem -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gir issues and maintenance
Martin, On 12/03/15 14:35, Martin Jansa wrote: > I was trying to use meta-gir in Dizzy release and found out that last > commit in this layer is 16 months ago and many .bbappends no longer > match with their recipes. > > Was this layer superseded by something else or you just didn't have time > to update it for newer Yocto releases? Unfortunately, life has been getting in the way of working on this layer (as well as meta-guacamayo), and it is not going to change in the foreseeable future. :-( It's a pity, as the gir stuff is useful/necessary for things like python bindings to gobject and related. If someone wanted to take over, it would make sense to move the repo somewhere more central (yocto, oe) as well. Tomas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] combo-layer: make Signed-off-by optional
Hi Patrick,
On Monday 09 March 2015 13:56:39 Patrick Ohly wrote:
> It depends on the diligence of the person running the combo-layer tool
> whether the Signed-off-by line added to each commit actually indicates
> that the person was involved in validating the change.
>
> When the import is purely automatic, it is better to not add the line,
> because the history is more useful without it (searching for the person
> really only lists changes he or she was involved with) and it would
> be a false statement.
>
> This needs to be configurable, achieved with a new global "signoff"
> boolean property in combo-layer.conf, in the "DEFAULT" section.
>
> Signed-off-by: Patrick Ohly
> ---
> scripts/combo-layer | 4 +++-
> scripts/combo-layer.conf.example | 6 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/combo-layer b/scripts/combo-layer
> index 19d64e6..60ead5b 100755
> --- a/scripts/combo-layer
> +++ b/scripts/combo-layer
> @@ -75,6 +75,8 @@ class Configuration(object):
> self.parser.readfp(f)
>
> self.repos = {}
> +self.signoff = not self.parser.has_option('DEFAULT', 'signoff') or
> \ + self.parser.getboolean('DEFAULT', 'signoff')
> for repo in self.parser.sections():
> self.repos[repo] = {}
> readsection(self.parser, repo, repo)
> @@ -471,7 +473,7 @@ def apply_patchlist(conf, repos):
> if os.path.getsize(patchfile) == 0:
> logger.info("(skipping %d/%d %s - no changes)" % (i,
> linecount, patchdisp)) else:
> -cmd = "git am --keep-cr -s -p1 %s" % patchfile
> +cmd = "git am --keep-cr %s-p1 %s" % ('-s ' if
> conf.signoff else '', patchfile) logger.info("Applying %d/%d: %s" % (i,
> linecount, patchdisp)) try:
> runcmd(cmd)
> diff --git a/scripts/combo-layer.conf.example
> b/scripts/combo-layer.conf.example index 010a692..8ad8615 100644
> --- a/scripts/combo-layer.conf.example
> +++ b/scripts/combo-layer.conf.example
> @@ -1,5 +1,11 @@
> # combo-layer example configuration file
>
> +# global options
> +[DEFAULT]
> +
> +# Add 'Signed-off-by' to all commits that get imported automatically.
> +signoff = True
> +
> # component name
> [bitbake]
> # mandatory options
So I'm OK with adding this in as an option. However to me a name like DEFAULT
implies you're establishing a general section to apply default settings for
all components where the component can override those defaults if it chooses,
which doesn't really represent what this does - so a different name might be
more appropriate (GLOBAL or _global_ perhaps?)
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] combo-layer: runcmd() with separate output
On Tuesday 10 March 2015 11:10:48 Patrick Ohly wrote:
> Allow the caller to specify a separate output stream. stderr is always
> a temporary file opened by runcmd(), so read from that to capture
> output for error reporting *and* the return value.
>
> The reasoning for the latter is a) that this preserves the traditional
> behavior when out=None and b) if the caller wants the content of
> stdout, it can read from the stream itself, which is not possible for
> the temporary stderr.
>
> Signed-off-by: Patrick Ohly
> ---
> scripts/combo-layer | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/combo-layer b/scripts/combo-layer
> index 5f10e83..fb3fb50 100755
> --- a/scripts/combo-layer
> +++ b/scripts/combo-layer
> @@ -149,23 +149,27 @@ class Configuration(object):
> logger.error("ERROR: patchutils package is missing, please
> install it (e.g. # apt-get install patchutils)") sys.exit(1)
>
> -def runcmd(cmd,destdir=None,printerr=True):
> +def runcmd(cmd,destdir=None,printerr=True,out=None):
> """
> execute command, raise CalledProcessError if fail
> return output if succeed
> """
> logger.debug("run cmd '%s' in %s" % (cmd, os.getcwd() if destdir is
> None else destdir)) -out = os.tmpfile()
> +if not out:
> +out = os.tmpfile()
> +err = out
> +else:
> +err = os.tmpfile()
> try:
> -subprocess.check_call(cmd, stdout=out, stderr=out, cwd=destdir,
> shell=True) +subprocess.check_call(cmd, stdout=out, stderr=err,
> cwd=destdir, shell=isinstance(cmd, str)) except
> subprocess.CalledProcessError,e:
> -out.seek(0)
> +err.seek(0)
> if printerr:
> -logger.error("%s" % out.read())
> +logger.error("%s" % err.read())
> raise e
>
> -out.seek(0)
> -output = out.read()
> +err.seek(0)
> +output = err.read()
> logger.debug("output: %s" % output )
> return output
I'm fine with this change, but FYI unfortunately we have a number of copies of
this function floating around. We'll probably end up having to do a refactoring
of these at some point soon.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] combo-layer: exclude files
On Tuesday 10 March 2015 11:10:49 Patrick Ohly wrote:
> Some combined repos intentionally do not include certain files.
> For example, Poky does not include bitbake's setup files and
> OE-core's sample files under meta/conf.
>
> When these files get modified in the upstream repository, applying the
> patches fails and requires manual intervention. That is merely a
> nuisance for someone familiar with the problem, but a real show
> stopper when having the import run automatically or by someone less
> experienced.
>
> Therefore this change introduces "file_exclude", a new per-repo list
> of file patterns which removes all matching files when initializing or
> updating a combined repository. Because fnmatch is used under the hood
> to match full path strings, removing entire directories must be done
> with a pattern ending in a '/*' (in contrast to file_filter).
>
> For Poky, the additional configuration looks like this:
>
> [bitbake]
> ...
> file_exclude = classes/base.bbclass
> conf/bitbake.conf
> .gitignore
> MANIFEST.in
> setup.py
> TODO
>
> [openembedded-core]
> ...
> file_exclude = meta/conf/bblayers.conf.sample
> meta/conf/local.conf.sample
> meta/conf/local.conf.sample.extended
> meta/conf/site.conf.sample
> ---
> scripts/combo-layer | 41
> +++- scripts/combo-layer.conf.example |
> 14 ++
> 2 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/combo-layer b/scripts/combo-layer
> index fb3fb50..b121c99 100755
> --- a/scripts/combo-layer
> +++ b/scripts/combo-layer
> @@ -20,6 +20,7 @@
> # with this program; if not, write to the Free Software Foundation, Inc.,
> # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>
> +import fnmatch
> import os, sys
> import optparse
> import logging
> @@ -208,7 +209,18 @@ def action_init(conf, args):
> else:
> extract_dir = os.getcwd()
> file_filter = repo.get('file_filter', "")
> -runcmd("git archive %s | tar -x -C %s %s" % (initialrev,
> extract_dir, file_filter), ldir) +files = runcmd("git archive
> %s | tar -x -v -C %s %s" % (initialrev, extract_dir, file_filter), ldir) +
> exclude_patterns = repo.get('file_exclude', '').split() +
>if exclude_patterns:
> +# Implement file removal by letting tar create the
> +# file and then deleting it in the file system
> +# again. Uses the list of files created by tar (easier
> +# than walking the tree).
> +for file in files.split('\n'):
> +for pattern in exclude_patterns:
> +if fnmatch.fnmatch(file, pattern):
> +os.unlink(os.path.join(extract_dir, file))
> +break
> if not lastrev:
> lastrev = runcmd("git rev-parse %s" % initialrev,
> ldir).strip() conf.update(name, "last_revision", lastrev, initmode=True) @@
> -423,6 +435,33 @@ def action_update(conf, args):
> runcmd("%s %s %s %s" % (repo['hook'], patch,
> revlist[count], name)) count=count-1
>
> +# Step 3a: Filter out unwanted files and patches.
> +exclude = repo.get('file_exclude', '')
> +if exclude:
> +filter = ['filterdiff', '-p1']
> +for path in exclude.split():
> +filter.append('-x')
> +filter.append(path)
> +for patch in patchlist[:]:
> +filtered = patch + '.tmp'
> +with open(filtered, 'w') as f:
> +runcmd(filter + [patch], out=f)
> +# Now check for empty patches.
> +if runcmd(['filterdiff', '--list', filtered]):
> +# Possibly modified.
> +os.unlink(patch)
> +os.rename(filtered, patch)
> +else:
> +# Empty, ignore it. Must also remove from revlist.
> +fromline = open(patch, 'r').readline()
Can you use "with open(..." here? Otherwise looks good.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl: Upgrade to 1.0.2
On 03/11/2015 11:18 PM, Robert Yang wrote: I met this error when building openflow in meta-networking, I guess it maybe related to the upgraded: x86_64-wrs-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/buildarea/lyang1/test_qemux86-64/bitbake_build/tmp/sysroots/qemux86-64 -Wstrict-prototypes -O2 -pipe -g -feliminate-unused-debug-types -Wall -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init -export-dynamic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o secchan/ofprotocol secchan/discovery.o secchan/emerg-flow.o secchan/fail-open.o secchan/failover.o secchan/in-band.o secchan/port-watcher.o secchan/protocol-stat.o secchan/ratelimit.o secchan/secchan.o secchan/status.o secchan/stp-secchan.o lib/libopenflow.a -ldl -L/buildarea/lyang1/test_qemux86-64/bitbake_build/tmp/sysroots/qemux86-64/usr/lib64 -lssl /buildarea/lyang1/test_qemux86-64/bitbake_build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-wrs-linux/gcc/x86_64-wrs-linux/4.9.2/ld: lib/libopenflow.a(vconn-ssl.o): undefined reference to symbol 'ERR_error_string@@OPENSSL_1.0.0' /buildarea/lyang1/test_qemux86-64/bitbake_build/tmp/sysroots/qemux86-64/lib64/libcrypto.so.1.0.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Robert, I am not sure about this, I just verified that ERR_error_string is a valid symbol in libcrypto.so, maybe you nbeed to have -lcrypto in addition to the -lssl on the command line for building openflow? I don't see it explicitly and maybe that's needed. Sau! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] combo-layer: make Signed-off-by optional
On Thu, 2015-03-12 at 18:21 +, Paul Eggleton wrote: > Hi Patrick, > > On Monday 09 March 2015 13:56:39 Patrick Ohly wrote: > > +# global options > > +[DEFAULT] > > + > > +# Add 'Signed-off-by' to all commits that get imported automatically. > > +signoff = True > > + > > # component name > > [bitbake] > > # mandatory options > > So I'm OK with adding this in as an option. However to me a name like DEFAULT > implies you're establishing a general section to apply default settings for > all components where the component can override those defaults if it chooses, > which doesn't really represent what this does - so a different name might be > more appropriate (GLOBAL or _global_ perhaps?) "DEFAULT" is the special string that Python's ConfigParser uses, well, by default for that special section which does not show up in the list of sections. I don't know how to rename that. I'm probably abusing this concept a bit here: it seems that special section is meant to provide default values that get returned also for the other sections when they don't have their own value. Here's a cleaner solution: * Get rid of the [DEFAULT] section in the file. * When reading it, on-the-fly prepend the string '[this-is-not-really-a-repo']. * When reading global properties, get it from that section. * When listing sections to find repos, ignore it. How about that? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] unzip: Add ALTERNATIVE configuration
Since busybox also provides the unzip command use the update-alternatives
mechanism to address this.
[YOCTO #7446]
Signed-off-by: Saul Wold
---
meta/recipes-extended/unzip/unzip_6.0.bb | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/recipes-extended/unzip/unzip_6.0.bb
b/meta/recipes-extended/unzip/unzip_6.0.bb
index 33c20f8..e203c06 100644
--- a/meta/recipes-extended/unzip/unzip_6.0.bb
+++ b/meta/recipes-extended/unzip/unzip_6.0.bb
@@ -35,4 +35,11 @@ do_install() {
rmdir ${D}${prefix}/man/
}
+inherit update-alternatives
+
+ALTERNATIVE_PRIORITY = "100"
+
+ALTERNATIVE_${PN} = "unzip"
+ALTERNATIVE_LINK_NAME[unzip] = "${bindir}/unzip"
+
BBCLASSEXTEND = "native"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel.bbclass: Fix race condition
Race condition between do_compile_kernelmodules and do_shared_workdir
tasks occurs when do_compilemodules changes files in include/generated/*
while do_shared_workdir tries to copy them to shared working directory.
Functionality of do_shared_workdir has been moved to separate function
mk_shared_workdir and called from do_kernel_compile. do_shared_workdir
left in the code as it may be used in many recipes.
[YOCTO #7321]
Signed-off-by: Ed Bartosh
---
meta/classes/kernel.bbclass | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 125ed88..aad430a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -231,6 +231,8 @@ kernel_do_install() {
[ -e Module.symvers ] && install -m 0644 Module.symvers
${D}/boot/Module.symvers-${KERNEL_VERSION}
install -d ${D}${sysconfdir}/modules-load.d
install -d ${D}${sysconfdir}/modprobe.d
+
+ mk_shared_workdir
}
do_install[prefuncs] += "package_get_auto_pr"
@@ -245,7 +247,7 @@ emit_depmod_pkgdata() {
PACKAGEFUNCS += "emit_depmod_pkgdata"
-do_shared_workdir () {
+mk_shared_workdir () {
cd ${B}
kerneldir=${STAGING_KERNEL_BUILDDIR}
@@ -289,6 +291,14 @@ do_shared_workdir () {
fi
}
+# NOTE!!! Functionality of do_shared_workdir has been moved to
mk_shared_workdir
+# and called from kernel_do_compile.
+# It caused race condition with do_compile_kernelmodules when it runs
+# in parallel with do_compile_kernelmodules
+do_shared_workdir () {
+ :
+}
+
# We don't need to stage anything, not the modules/firmware since those would
clash with linux-firmware
sysroot_stage_all () {
:
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] tar: set acpaths to avoid "Argument list too long" error
On 03/12/2015 08:16 PM, Burton, Ross wrote:
On 12 March 2015 at 06:14, Robert Yang mailto:liezhi.y...@windriver.com>> wrote:
+acpaths = "-I ./m4"
Why does this only happen on tar? Why is it safe to pass just -I ./m4 when the
detected list that you're overriding is effectively -I ./m4 -I ./tests?
Not only tar has this problem, but also other recipes such as coreutils,
because they have many 4 files, but we have fixed that others bfore,
for example:
commit 238e9b54e228b850434f7d503870e86cfb12b775
Author: Robert Yang
Date: Sun Sep 15 09:13:12 2013 +
coreutils: set acpaths to avoid "Argument list too long" error
Now I tested the build in the deep directory again, only found tar
failed, and Chong had made a patch for it.
If we don't set 'acpaths = "-I ./m4"', then it would use the absolute path,
which would be too long, here is the related code in autotools.bbclass
for acpaths:
acpaths = "default"
[snip]
ACLOCAL="aclocal --system-acdir=${ACLOCALDIR}/"
if [ x"${acpaths}" = xdefault ]; then
acpaths=
for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 'aclocal.m4'| \
grep -v 'acinclude.m4' | grep -v 'aclocal-copy' | sed -e
's,\(.*/\).*$,\1,'|sort -u`; do
acpaths="$acpaths -I $i"
done
else
acpaths="${acpaths}"
fi
I think it's safe to set acpaths = "-I ./m4" as we had done for coreutils.
// Robert
Would it be better to just make all include paths relative to ${S} when
generating the acpaths?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
