Re: [OE-core] [oe-commits] Richard Purdie : sstatesig/sstate: Add support for locked down sstate cache usage
On 09/09/2014 05:30 PM, Hongxu Jia wrote:
On 09/05/2014 07:29 PM, g...@opal.openembedded.org wrote:
Module: openembedded-core.git
Branch: master-next
Commit: a12e33a584a77df4bdd9ad6a5d1a58f4dde10317
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=a12e33a584a77df4bdd9ad6a5d1a58f4dde10317
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date: Fri Sep 5 10:40:02 2014 +0100
sstatesig/sstate: Add support for locked down sstate cache usage
I've been giving things some thought, specifically why sstate doesn't
get used more and why we have people requesting external toolchains. I'm
guessing the issue is that people don't like how often sstate can change
and the lack of an easy way to lock it down.
Locking it down is actually quite easy so patch implements some basics
of how you can do this (for example to a specific toolchain). With an
addition like this to local.conf (or wherever):
SIGGEN_LOCKEDSIGS = \
gcc-cross:do_populate_sysroot:a8d91b35b98e1494957a2ddaf4598956 \
eglibc:do_populate_sysroot:13e8c68553dc61f9d67564f13b9b2d67 \
eglibc:do_packagedata:bfca0db1782c719d373f8636282596ee \
gcc-cross:do_packagedata:4b601ff4f67601395ee49c46701122f6 \
the code at the end of the email will force the hashes to those values
for the recipes mentioned. The system would then find and use those
specific objects from the sstate cache instead of trying to build
anything.
Obviously this is a little simplistic, you might need to put an override
against this to only apply those revisions for a specific architecture
for example. You'd also probably want to put code in the sstate hash
validation code to ensure it really did install these from sstate since
if it didn't you'd want to abort the build.
This patch also implements support to add to bitbake -S which dumps the
locked sstate checksums for each task into a ready prepared include file
locked-sigs.inc (currently placed into cwd). There is a function,
bb.parse.siggen.dump_lockedsigs() which can be called to trigger the
same functionality from task space.
A warning is added to sstate.bbclass through a call back into the siggen
class to warn if objects are not used from the locked cache. The
SIGGEN_ENFORCE_LOCKEDSIGS variable controls whether this is just a
warning
or a fatal error.
A script is provided to generate sstate directory from a locked-sigs
file.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/sstate.bbclass | 3 ++
meta/lib/oe/sstatesig.py| 74
+
scripts/gen-lockedsig-cache | 40
3 files changed, 117 insertions(+)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index ead829e..6316336 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -710,6 +710,9 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash,
sq_hashfn, d):
evdata['found'].append( (sq_fn[task], sq_task[task],
sq_hash[task], sstatefile ) )
bb.event.fire(bb.event.MetadataEvent(MissedSstate,
evdata), d)
+if hasattr(bb.parse.siggen, checkhashes):
+bb.parse.siggen.checkhashes(missed, ret, sq_fn, sq_task,
sq_hash, sq_hashfn, d)
+
Hi Richard,
I have investigated and tested your patches, and found out invoking
bb.parse.siggen.checkhashes in sstate_checkhashes didn't work,
the ret and missed will alway be empty.
Once locked-sigs.inc file generated and included, taskhash will never be
changed which is replaced from locked-sigs.inc in get_taskhash, the ret
and missed will alway be empty.
...
WARNING: Using db-native do_fetch 29c5815138c74ce818863772e4a4
WARNING: Using quilt-native do_fetch 43ac1a25892c6c7d16e2dd36c61405d8
...
WARNING: ret []
WARNING: missed []
...
Oh, it's my fault, you means a warning is added to sstate.bbclass through
a call back into the siggen class to warn if *objects are not used from the
locked cache*.
What I tested and wanted is a warn/error while hashes changed and using
locked sig instead.
They are two different things, sorry for the misunderstanding.
We hope bitbake could support to add hook at BB_HASHCHECK_FUNCTION,
so the users to customize their own sstate-cache hash checking mechanism,
(Such as sign/verify sstate-cache with pgp/gpg mechanism for security
purpose)
As you mentioned, I could use BB_SIGNATURE_HANDLER to do that, sorry for
the nosiy.
//Hongxu
//Hongxu
return ret
BB_SETSCENE_DEPVALID = setscene_depvalid
diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 4188873..7b860c5 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -61,6 +61,16 @@ def sstate_rundepfilter(siggen, fn, recipename,
task, dep, depname, dataCache):
# Default to keep dependencies
return True
+def sstate_lockedsigs(d):
+sigs = {}
+lockedsigs = (d.getVar(SIGGEN_LOCKEDSIGS, True) or ).split()
+for ls in lockedsigs:
+pn, task, h = ls.split(:, 2)
+
Re: [OE-core] Packaging kernel sources
Good idea, how about use the name linux-source, but add custom in the summary or description. // Robert On 09/10/2014 08:42 AM, Darren Hart wrote: Hi all, I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Koen, I believe you had a solution for this with Angstrom? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Packaging kernel sources
On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote: I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Personally, I'm leaning towards a couple of big changes in this area: a) binning the kernel-dev package and replacing it with some kind of separate full source recipe like this. The benefit is a fully functional on target source which is only built by people who care about it. This means for most users/builds, we no longer need to generate that huge package. The downside is a little more complexity for those that needs this but its not much. b) binning the separate kernel staging dir and making it work more like the gcc shared work directory. This means external module builds and the tools like perf and so on would use this shared source directory. The benefit would be that we no longer have the huge install step in the main kernel recipe and the populate_sysroot step shinks in size. The downside has more impact here, the problem with shared work is that it cannot be removed once extracted since the system never knows when something else may need to use it. For gcc the argument was that we have so many users (gcc-cross-initial, gcc-cross, gcc-runtime, gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that the multiple copies were far worse. For the kernel, we can argue that we have a ton of disk usage from it in the sysroot anyway so this change just makes things more efficient effectively. The other issue is that for shared work dirs, the stamps need to be kept in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack, do_patch task checksums need to match for linux-yocto, perf, kernel modules and anything else using it). We may need to add some better error cases to catch problems. Not an insurmountable problem, just one that will likely need to be addressed. I do feel the whole situation with the current kernel size is out of control and badly affecting user experience. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] hash generation for PR Service?
I'm not sure if this is the right mailing list for our problem. Please forgive me if not (and tell me the right one). We're investigating some problems related with package versions going backwards using a PR Service[1]. Can someone give some hints where we can get information about generation of the hashes which are used to request values from the PR service? Especially which data/files/directories are involved.. [1] https://wiki.yoctoproject.org/wiki/PR_Service -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Backporting of latest recipes on oe-classic
Hi Paul, Do you know any forked repository where we can found support for glibc 2.11.x, 2.12.x onwards. One more query is related to glibc version. Does it become eglibc in later versions as we could not get later version recipes. Actually i have an old infra and i need to support icaclient 13 (citrix receiver) which require libraries of later versions e.g. glibc, gtk, libwebkit... Regards Bryan On Sep 9, 2014 6:32 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Tuesday 09 September 2014 18:23:24 Bryan wrote: We have some queries regarding OE-Classic. 1. Where can we find latest recipes for oe-classic. http://cgit.openembedded.org/cgit.cgi/openembedded/ That's as up-to-date as it gets. There might be other forked repositories floating around, but that is the last official one. Does oe-classic is still get updation for latest package support? No, as discussed on IRC, OE-Classic is now unmaintained. OE-Core and layers on top of it should ideally be used instead. 2. How can we compile latest recipes of oe-core on oe-classic and ofcourse there bitbake version would be different.Basically, we can say we need to backport the recipe to classic. e.g. gtk+2.20.1 above, glibc-2.11.3 above If you are determined to stay with OE-Classic I think you'd be better off just upgrading the recipes in OE-Classic - going backwards is going to be more painful. Here's the only semi-related information we have, which is about migration in the other direction; it could be helpful in terms of providing pointers: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/21] C-Pull
Hi,
Misc patches, kernel-dev upgrade, QA support for automated ptest execution.
The initial full nightly autobuilder run failed dramatically due to valgrind
failing to configure. This is now fixed, and verified with a run of
nightly-x86-64.
Ross
The following changes since commit 0d3c79524c95a7ab3b87c9dcb49746746900a18a:
glibc: Incremental bump to 2.20 release branch (2014-09-10 11:33:26 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib ross/mut-next
for you to fetch changes up to 0975ff62201ae6745fdf2e2e5a62c8157a73669e:
nspr: Upgrade to 4.10.7 (2014-09-10 11:47:20 +0100)
Bruce Ashfield (7):
linux-yocto/3.10: baytrail i/o updates
lttng-modules: fix compilation for 3.17-rcX
perf: fix v3.17 powerpc compilation issues
linux-yocto: introduce v3.17
linux-yocto/3.10: update valleyisland-io merge branch
linux-yocto/3.14: configuration updates and feature merges.
linux-yocto-dev: bump to v3.17+
Carlos Rafael Giani (1):
kernel.bbclass: handle .dsp firmware
Chen Qi (1):
bitbake.conf: use ??= for IMAGE_ROOTFS_SIZE
Jackie Huang (1):
packagegroup-self-hosted: move graphics packages to graphics group
Lucian Musat (3):
oeqa: Added package installer to oetest to aid in future automatic
install of packages
oeqa/utils/logparser.py: results based log parser utility
oeqa/runtime: Automatic test for ptest
Otavio Salvador (1):
packagegroup.bbclass: Use immediate expanded PACKAGE_ARCH value
Paul Eggleton (1):
classes/buildhistory: fix for sstate class change
Ross Burton (4):
e2fsprogs: remove chmod
e2fsprogs: enable verbose build
e2fsprogs: remove manual build of util/subst
e2fsprogs: update acinclude.m4
Saul Wold (1):
nspr: Upgrade to 4.10.7
Sona Sarmadi (1):
pcihp: fix possible array out of bounds, CVE-2014-5388
meta/classes/buildhistory.bbclass |2 +-
meta/classes/kernel.bbclass|1 +
meta/classes/packagegroup.bbclass |8 +-
meta/conf/bitbake.conf |2 +-
meta/lib/oeqa/oetest.py|7 ++
meta/lib/oeqa/runtime/_ptest.py| 124 +++
meta/lib/oeqa/utils/logparser.py | 125 +++
.../packagegroups/packagegroup-self-hosted.bb | 10 +-
.../e2fsprogs/e2fsprogs/acinclude.m4 | 53 +++-
.../recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb |7 +-
...1-Back-porting-security-fix-CVE-2014-5388.patch | 30 +
meta/recipes-devtools/qemu/qemu_2.1.0.bb |1 +
meta/recipes-kernel/linux/linux-yocto-dev.bb |2 +-
meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb |6 +-
meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb |6 +-
meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |4 +-
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |4 +-
meta/recipes-kernel/linux/linux-yocto-tiny_3.17.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.10.bb | 16 +--
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 16 +--
meta/recipes-kernel/linux/linux-yocto_3.17.bb | 37 ++
...probes-should-calculate-alignment-and-eve.patch | 130
...e-kvm-instrumentation-compile-on-3.17-rc1.patch | 46 +++
.../Update-statedump-to-3.17-nsproxy-locking.patch | 70 +++
meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb |3 +
meta/recipes-kernel/perf/perf.bb |5 +
.../nspr/nspr/fix-build-on-x86_64.patch| 31 ++---
.../nspr/remove-srcdir-from-configure-in.patch | 19 +++
.../nspr/nspr/trickly-fix-build-on-x86_64.patch| 62 --
.../nspr/{nspr_4.10.3.bb = nspr_4.10.7.bb}| 13 +-
30 files changed, 730 insertions(+), 131 deletions(-)
create mode 100644 meta/lib/oeqa/runtime/_ptest.py
create mode 100644 meta/lib/oeqa/utils/logparser.py
create mode 100644
meta/recipes-devtools/qemu/files/0001-Back-porting-security-fix-CVE-2014-5388.patch
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.17.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.17.bb
create mode 100644
meta/recipes-kernel/lttng/lttng-modules/Fix-noargs-probes-should-calculate-alignment-and-eve.patch
create mode 100644
meta/recipes-kernel/lttng/lttng-modules/Update-kvm-instrumentation-compile-on-3.17-rc1.patch
create mode 100644
meta/recipes-kernel/lttng/lttng-modules/Update-statedump-to-3.17-nsproxy-locking.patch
create mode 100644
meta/recipes-support/nspr/nspr/remove-srcdir-from-configure-in.patch
delete mode 100644
meta/recipes-support/nspr/nspr/trickly-fix-build-on-x86_64.patch
rename meta/recipes-support/nspr/{nspr_4.10.3.bb = nspr_4.10.7.bb} (91%)
Bruce Ashfield (7):
linux-yocto/3.10: baytrail i/o updates
Re: [OE-core] [oe] Backporting of latest recipes on oe-classic
On Wednesday 10 September 2014 19:13:58 Bryan wrote: Hi Paul, Do you know any forked repository where we can found support for glibc 2.11.x, 2.12.x onwards. I don't, no, sorry. I don't keep track of OE-Classic forks and OpenEmbedded no longer maintains OE-Classic. 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] [oe] Backporting of latest recipes on oe-classic
Can u please tell me which latest bitbake version i can use with oe-classic. I used bitbake version 1.8.12 with my infra. So i need to use bitbake version which would be suitable with my old recipes as well. Regards Bryan On Sep 10, 2014 7:13 PM, Bryan just4tec...@gmail.com wrote: Hi Paul, Do you know any forked repository where we can found support for glibc 2.11.x, 2.12.x onwards. One more query is related to glibc version. Does it become eglibc in later versions as we could not get later version recipes. Actually i have an old infra and i need to support icaclient 13 (citrix receiver) which require libraries of later versions e.g. glibc, gtk, libwebkit... Regards Bryan On Sep 9, 2014 6:32 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Tuesday 09 September 2014 18:23:24 Bryan wrote: We have some queries regarding OE-Classic. 1. Where can we find latest recipes for oe-classic. http://cgit.openembedded.org/cgit.cgi/openembedded/ That's as up-to-date as it gets. There might be other forked repositories floating around, but that is the last official one. Does oe-classic is still get updation for latest package support? No, as discussed on IRC, OE-Classic is now unmaintained. OE-Core and layers on top of it should ideally be used instead. 2. How can we compile latest recipes of oe-core on oe-classic and ofcourse there bitbake version would be different.Basically, we can say we need to backport the recipe to classic. e.g. gtk+2.20.1 above, glibc-2.11.3 above If you are determined to stay with OE-Classic I think you'd be better off just upgrading the recipes in OE-Classic - going backwards is going to be more painful. Here's the only semi-related information we have, which is about migration in the other direction; it could be helpful in terms of providing pointers: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core 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] Packaging kernel sources
On 14-09-10 04:27 AM, Richard Purdie wrote: On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote: I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Personally, I'm leaning towards a couple of big changes in this area: I'd prefer this sort of larger switch as well. a) binning the kernel-dev package and replacing it with some kind of separate full source recipe like this. The benefit is a fully functional on target source which is only built by people who care about it. This means for most users/builds, we no longer need to generate that huge package. The downside is a little more complexity for those that needs this but its not much. And just so I'm clear, in this case, the current sysroot, grep, sed, hack-a-thon version of the kernel would stay as is ? b) binning the separate kernel staging dir and making it work more like the gcc shared work directory. This means external module builds and the tools like perf and so on would use this shared source directory. The benefit would be that we no longer have the huge install step in the main kernel recipe and the populate_sysroot step shinks in size. The downside has more impact here, the problem with shared work is that it cannot be removed once extracted since the system never knows when something else may need to use it. For gcc the argument was that we have so many users (gcc-cross-initial, gcc-cross, gcc-runtime, gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that the multiple copies were far worse. For the kernel, we can argue that we have a ton of disk usage from it in the sysroot anyway so this change just makes things more efficient effectively. The other issue is that for shared work dirs, the stamps need to be kept in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack, do_patch task checksums need to match for linux-yocto, perf, kernel modules and anything else using it). We may need to add some better error cases to catch problems. Not an insurmountable problem, just one that will likely need to be addressed. I do feel the whole situation with the current kernel size is out of control and badly affecting user experience. I like (b) myself, since I'm getting tired of copying the source tree, having the removals fail as we march forward through kernel versions, and then needing to modify everything from the SDK to the out of tree module builds to reconstruct scripts, etc. We'd have the same don't patch it restrictions for something that builds out of this shared directory (like perf), so there's nothing new and horrible there. Cheers, Bruce Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Backporting of latest recipes on oe-classic
On Wednesday 10 September 2014 19:39:58 Bryan wrote: Can u please tell me which latest bitbake version i can use with oe-classic. I used bitbake version 1.8.12 with my infra. So i need to use bitbake version which would be suitable with my old recipes as well. If you use 1.8.12 and it works, wouldn't you just stick with that? 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] Packaging kernel sources
On Wed, 2014-09-10 at 10:11 -0400, Bruce Ashfield wrote: On 14-09-10 04:27 AM, Richard Purdie wrote: On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote: I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Personally, I'm leaning towards a couple of big changes in this area: I'd prefer this sort of larger switch as well. a) binning the kernel-dev package and replacing it with some kind of separate full source recipe like this. The benefit is a fully functional on target source which is only built by people who care about it. This means for most users/builds, we no longer need to generate that huge package. The downside is a little more complexity for those that needs this but its not much. And just so I'm clear, in this case, the current sysroot, grep, sed, hack-a-thon version of the kernel would stay as is ? No, these are two things I think we need to do together. There are two issues, the on target one and the sysroot mess. a) deals with the former, b) the latter. So b) takes care of the hack-a-thon but I think we need a) as well. b) binning the separate kernel staging dir and making it work more like the gcc shared work directory. This means external module builds and the tools like perf and so on would use this shared source directory. The benefit would be that we no longer have the huge install step in the main kernel recipe and the populate_sysroot step shinks in size. The downside has more impact here, the problem with shared work is that it cannot be removed once extracted since the system never knows when something else may need to use it. For gcc the argument was that we have so many users (gcc-cross-initial, gcc-cross, gcc-runtime, gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that the multiple copies were far worse. For the kernel, we can argue that we have a ton of disk usage from it in the sysroot anyway so this change just makes things more efficient effectively. The other issue is that for shared work dirs, the stamps need to be kept in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack, do_patch task checksums need to match for linux-yocto, perf, kernel modules and anything else using it). We may need to add some better error cases to catch problems. Not an insurmountable problem, just one that will likely need to be addressed. I do feel the whole situation with the current kernel size is out of control and badly affecting user experience. I like (b) myself, since I'm getting tired of copying the source tree, having the removals fail as we march forward through kernel versions, and then needing to modify everything from the SDK to the out of tree module builds to reconstruct scripts, etc. We'd have the same don't patch it restrictions for something that builds out of this shared directory (like perf), so there's nothing new and horrible there. Right... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Packaging kernel sources
On 14-09-10 10:24 AM, Richard Purdie wrote: On Wed, 2014-09-10 at 10:11 -0400, Bruce Ashfield wrote: On 14-09-10 04:27 AM, Richard Purdie wrote: On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote: I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Personally, I'm leaning towards a couple of big changes in this area: I'd prefer this sort of larger switch as well. a) binning the kernel-dev package and replacing it with some kind of separate full source recipe like this. The benefit is a fully functional on target source which is only built by people who care about it. This means for most users/builds, we no longer need to generate that huge package. The downside is a little more complexity for those that needs this but its not much. And just so I'm clear, in this case, the current sysroot, grep, sed, hack-a-thon version of the kernel would stay as is ? No, these are two things I think we need to do together. There are two issues, the on target one and the sysroot mess. a) deals with the former, b) the latter. So b) takes care of the hack-a-thon but I think we need a) as well. Aha. With your clarification, I can see the difference now .. I hadn't had coffee yet. Grabbing a full source copy for the on-target needs, and not just the source that we've mangled or changed for our build purposes. Agreed that this also cleans up the target needs for kernel source and build. Bruce b) binning the separate kernel staging dir and making it work more like the gcc shared work directory. This means external module builds and the tools like perf and so on would use this shared source directory. The benefit would be that we no longer have the huge install step in the main kernel recipe and the populate_sysroot step shinks in size. The downside has more impact here, the problem with shared work is that it cannot be removed once extracted since the system never knows when something else may need to use it. For gcc the argument was that we have so many users (gcc-cross-initial, gcc-cross, gcc-runtime, gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that the multiple copies were far worse. For the kernel, we can argue that we have a ton of disk usage from it in the sysroot anyway so this change just makes things more efficient effectively. The other issue is that for shared work dirs, the stamps need to be kept in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack, do_patch task checksums need to match for linux-yocto, perf, kernel modules and anything else using it). We may need to add some better error cases to catch problems. Not an insurmountable problem, just one that will likely need to be addressed. I do feel the whole situation with the current kernel size is out of control and badly affecting user experience. I like (b) myself, since I'm getting tired of copying the source tree, having the removals fail as we march forward through kernel versions, and then needing to modify everything from the SDK to the out of tree module builds to reconstruct scripts, etc. We'd have the same don't patch it restrictions for something that builds out of this shared directory (like perf), so there's nothing new and horrible there. Right... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/21] C-Pull
On Wed, 2014-09-10 at 14:49 +0100, Ross Burton wrote: Hi, Misc patches, kernel-dev upgrade, QA support for automated ptest execution. The initial full nightly autobuilder run failed dramatically due to valgrind failing to configure. This is now fixed, and verified with a run of nightly-x86-64. Thanks, I've merged this. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] curl: upgrade to 7.38.0
Fixes two HTTP cookie related security bugs:
1. CVE-2014-3613
2. CVE-2014-3620
Changelog:
http://curl.haxx.se/changes.html#7_38_0
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
meta/recipes-support/curl/{curl_7.37.1.bb = curl_7.38.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/curl/{curl_7.37.1.bb = curl_7.38.0.bb} (93%)
diff --git a/meta/recipes-support/curl/curl_7.37.1.bb
b/meta/recipes-support/curl/curl_7.38.0.bb
similarity index 93%
rename from meta/recipes-support/curl/curl_7.37.1.bb
rename to meta/recipes-support/curl/curl_7.38.0.bb
index 8bcd9ba..3077074 100644
--- a/meta/recipes-support/curl/curl_7.37.1.bb
+++ b/meta/recipes-support/curl/curl_7.38.0.bb
@@ -14,8 +14,8 @@ SRC_URI = http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
#
SRC_URI += file://configure_ac.patch
-SRC_URI[md5sum] = 95c627abcf6494f5abe55effe7cd6a57
-SRC_URI[sha256sum] =
c3ef3cd148f3778ddbefb344117d7829db60656efe1031f9e3065fc0faa25136
+SRC_URI[md5sum] = af6b3c299bd891f43cb5f76c4091b7b4
+SRC_URI[sha256sum] =
035bd41e99aa1a4e64713f4cea5ccdf366ca8199e9be1b53d5a043d5165f9eba
inherit autotools pkgconfig binconfig multilib_header
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Packaging kernel sources
On 9/10/14, 1:27, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote: I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Personally, I'm leaning towards a couple of big changes in this area: a) binning the kernel-dev package and replacing it with some kind of separate full source recipe like this. The benefit is a fully functional on target source which is only built by people who care about it. This means for most users/builds, we no longer need to generate that huge package. The downside is a little more complexity for those that needs this but its not much. The other downside is that the most common use case (building external modules) would now require a lot more disk space than with just kernel-dev (something like 150 MB more iirc). b) binning the separate kernel staging dir and making it work more like the gcc shared work directory. This means external module builds and the tools like perf and so on would use this shared source directory. I was thinking along the same lines here as well. The benefit would be that we no longer have the huge install step in the main kernel recipe and the populate_sysroot step shinks in size. The downside has more impact here, the problem with shared work is that it cannot be removed once extracted since the system never knows when something else may need to use it. For gcc the argument was that we have so many users (gcc-cross-initial, gcc-cross, gcc-runtime, gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that the multiple copies were far worse. For the kernel, we can argue that we have a ton of disk usage from it in the sysroot anyway so this change just makes things more efficient effectively. The other issue is that for shared work dirs, the stamps need to be kept in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack, do_patch task checksums need to match for linux-yocto, perf, kernel modules and anything else using it). We may need to add some better error cases to catch problems. Not an insurmountable problem, just one that will likely need to be addressed. Good points. I do feel the whole situation with the current kernel size is out of control and badly affecting user experience. Yup. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Packaging kernel sources
On 14-09-10 11:27 AM, Brandt, Todd E wrote:
I think David brings up a good point about only needing the kernel
source when something goes wrong. How about a compromise. What if we
provided a simply utility which pulls in the kernel source and
recreates the existing kernel image by using git (with the proper
commit). It could be installed from within the kernel package and be
generated by the linux-kernel recipe so that it has the proper commit
hashes (like a simple bash script). That way there's no wasted space.
I think I might just do that for the heck of it anyway.
We have to respect however the kernel was built, patched, etc. So it
just needs to be whatever was in the ${S} of what was built. Much of
anything else would be recreating the patch process of the kernel
build .. or maybe I'm misunderstanding what you are suggesting.
Bruce
From: Darren Hart [dvh...@linux.intel.com]
Sent: Wednesday, September 10, 2014 8:13 AM
To: Richard Purdie; Ashfield, Bruce (Wind River)
Cc: Openembedded-core@lists.openembedded.org; Brandt, Todd E; Koen Kooi; Tom
Zanussi
Subject: Re: [OE-core] Packaging kernel sources
On 9/10/14, 1:27, Richard Purdie richard.pur...@linuxfoundation.org
wrote:
On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote:
I'm working on a project which needs to have the full kernel sources
installed on the target. The kernel-dev package as defined by
kernel.bbclass is heavily pruned to minimize packaging time and size and
is intended to enable building of external modules on the target.
Is there an accepted best-practice for how to get the full source
packaged
and installed? I can easily write a new recipe,
linux-custom-source_git.bb, to install the sources, for example, without
impacting the packaging time of virtual/kernel package.
It would be nice in some respects for it to all come from the same
recipe
though, but I suspect the impact to the common-case where this is not
need
would be far too great.
Personally, I'm leaning towards a couple of big changes in this area:
a) binning the kernel-dev package and replacing it with some kind of
separate full source recipe like this.
The benefit is a fully functional on target source which is only built
by people who care about it. This means for most users/builds, we no
longer need to generate that huge package. The downside is a little more
complexity for those that needs this but its not much.
The other downside is that the most common use case (building external
modules) would now require a lot more disk space than with just kernel-dev
(something like 150 MB more iirc).
b) binning the separate kernel staging dir and making it work more like
the gcc shared work directory. This means external module builds and the
tools like perf and so on would use this shared source directory.
I was thinking along the same lines here as well.
The benefit would be that we no longer have the huge install step in the
main kernel recipe and the populate_sysroot step shinks in size.
The downside has more impact here, the problem with shared work is that
it cannot be removed once extracted since the system never knows when
something else may need to use it. For gcc the argument was that we have
so many users (gcc-cross-initial, gcc-cross, gcc-runtime,
gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that
the multiple copies were far worse. For the kernel, we can argue that we
have a ton of disk usage from it in the sysroot anyway so this change
just makes things more efficient effectively.
The other issue is that for shared work dirs, the stamps need to be kept
in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack,
do_patch task checksums need to match for linux-yocto, perf, kernel
modules and anything else using it). We may need to add some better
error cases to catch problems. Not an insurmountable problem, just one
that will likely need to be addressed.
Good points.
I do feel the whole situation with the current kernel size is out of
control and badly affecting user experience.
Yup.
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Packaging kernel sources
On 09/10/2014 10:13 AM, Darren Hart wrote:
On 9/10/14, 1:27, Richard Purdie richard.pur...@linuxfoundation.org
wrote:
On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote:
I'm working on a project which needs to have the full kernel sources
installed on the target. The kernel-dev package as defined by
kernel.bbclass is heavily pruned to minimize packaging time and size and
is intended to enable building of external modules on the target.
Is there an accepted best-practice for how to get the full source
packaged
and installed? I can easily write a new recipe,
linux-custom-source_git.bb, to install the sources, for example, without
impacting the packaging time of virtual/kernel package.
It would be nice in some respects for it to all come from the same
recipe
though, but I suspect the impact to the common-case where this is not
need
would be far too great.
Personally, I'm leaning towards a couple of big changes in this area:
a) binning the kernel-dev package and replacing it with some kind of
separate full source recipe like this.
The benefit is a fully functional on target source which is only built
by people who care about it. This means for most users/builds, we no
longer need to generate that huge package. The downside is a little more
complexity for those that needs this but its not much.
The other downside is that the most common use case (building external
modules) would now require a lot more disk space than with just kernel-dev
(something like 150 MB more iirc).
There are three use cases where I've wanted kernel source on target:
1) Building the whole kernel. Pretty rare, but could happen. Debian
appears to provide a linux-source package that provides the whole source
in /usr/src/linux-source-$(uname -r). I'd want it to come with the
contents of ${S} at the point where the compile task was ready to run.
I'd love it to also come with a shallow git repository already present:
I can't see anybody wanting to do on-target kernel modifications without
having SCM underneath, and it takes a long time to git add --all a
kernel tree on a class 4 uSD card. It doesn't need the entire history,
just maybe three commits: the upstream stable base release, a record of
the changes/patches done by kern-tools or other kernel-building recipes,
and a final commit that archives the as-built .config as a defconfig
somewhere.
2) Building external modules. Very common, and AFAICT normally packaged
as linux-headers on debian systems, living in
/usr/src/linux-headers-$(uname -r). I think simply renaming kernel-dev
to this and changing where it unpacks would do. No need for git here
since its unlikely people would be modifying the headers.
3) Building device trees. I haven't figured out how to do this other
than rebuilding the whole kernel which is a major pain, but inspection
suggests the current kernel-dev (proposed linux-headers) might have that
functionality.
Peter
b) binning the separate kernel staging dir and making it work more like
the gcc shared work directory. This means external module builds and the
tools like perf and so on would use this shared source directory.
I was thinking along the same lines here as well.
The benefit would be that we no longer have the huge install step in the
main kernel recipe and the populate_sysroot step shinks in size.
The downside has more impact here, the problem with shared work is that
it cannot be removed once extracted since the system never knows when
something else may need to use it. For gcc the argument was that we have
so many users (gcc-cross-initial, gcc-cross, gcc-runtime,
gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that
the multiple copies were far worse. For the kernel, we can argue that we
have a ton of disk usage from it in the sysroot anyway so this change
just makes things more efficient effectively.
The other issue is that for shared work dirs, the stamps need to be kept
in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack,
do_patch task checksums need to match for linux-yocto, perf, kernel
modules and anything else using it). We may need to add some better
error cases to catch problems. Not an insurmountable problem, just one
that will likely need to be addressed.
Good points.
I do feel the whole situation with the current kernel size is out of
control and badly affecting user experience.
Yup.
I don't know that there's much that can be done: I wouldn't want
anything removing parts of the source tree from a kernel on a
presumption that the user wouldn't want them installed. But yeah, the
thing's a pig.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] classes/populate_sdk_base: enable adding custom commands to SDK install script
Add an SDK_POST_INSTALL_COMMAND variable which allows additional
commands to be added towards the end of the SDK install script, for e.g.
additional processing that needs to be done as part of installing the
SDK.
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/populate_sdk_base.bbclass | 7 +++
meta/files/toolchain-shar-template.sh | 2 ++
2 files changed, 9 insertions(+)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index abfcdc7..946a1d4 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -51,6 +51,7 @@ PID = ${@os.getpid()}
EXCLUDE_FROM_WORLD = 1
SDK_PACKAGING_FUNC ?= create_shar
+SDK_POST_INSTALL_COMMAND ?=
SDK_MANIFEST = ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.manifest
python write_target_sdk_manifest () {
@@ -142,10 +143,16 @@ fakeroot create_shar() {
# copy in the template shar extractor script
cp ${COREBASE}/meta/files/toolchain-shar-template.sh
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+ cat EOF ${T}/post_install_command
+${SDK_POST_INSTALL_COMMAND}
+EOF
+ sed -i -e '/@SDK_POST_INSTALL_COMMAND@/r ${T}/post_install_command'
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+
# substitute variables
sed -i -e 's#@SDK_ARCH@#${SDK_ARCH}#g' \
-e 's#@SDKPATH@#${SDKPATH}#g' \
-e
's#@REAL_MULTIMACH_TARGET_SYS@#${REAL_MULTIMACH_TARGET_SYS}#g' \
+ -e '/@SDK_POST_INSTALL_COMMAND@/d' \
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
# add execution permission
diff --git a/meta/files/toolchain-shar-template.sh
b/meta/files/toolchain-shar-template.sh
index a37d6ff..02035d4 100644
--- a/meta/files/toolchain-shar-template.sh
+++ b/meta/files/toolchain-shar-template.sh
@@ -169,6 +169,8 @@ done
echo done
+@SDK_POST_INSTALL_COMMAND@
+
# delete the relocating script, so that user is forced to re-run the installer
# if he/she wants another location for the sdk
if [ $savescripts = 0 ] ; then
--
1.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Locked sstate / SDK changes
A couple of changes related to the developer workflow work (see https://bugzilla.yoctoproject.org/show_bug.cgi?id=6662 ). Unfortunately the user facing parts of that are some way off being ready for submission but here are a couple of the minimal core pieces we need to make those work. (Note that these are on top of Richard's locked sigs changes that are still in review.) The following changes since commit 00e869965818a08cec1ec4f48c35dcf0fe0d6959: sstatesig: Improve to handle locking of multiple machines (2014-09-10 18:15:41 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/sdkchanges http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/sdkchanges Paul Eggleton (1): classes/populate_sdk_base: enable adding custom commands to SDK install script Randy Witt (1): sstatesig.py: Add a path argument to dump_lockedsigs() meta/classes/populate_sdk_base.bbclass | 7 +++ meta/files/toolchain-shar-template.sh | 2 ++ meta/lib/oe/sstatesig.py | 7 --- 3 files changed, 13 insertions(+), 3 deletions(-) -- 1.9.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] sstatesig.py: Add a path argument to dump_lockedsigs()
From: Randy Witt randy.e.w...@linux.intel.com
Previously the function always used os.getcwd() for the location to
write the locked signatures file. However, that isn't easily used by
calling tasks, so only use os.getcwd() if the caller doesn't specify
a path.
Signed-off-by: Randy Witt randy.e.w...@linux.intel.com
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/lib/oe/sstatesig.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index add2619..9fcbc2b 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -130,8 +130,9 @@ class
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
return
super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigtask(fn,
task, stampbase, runtime)
-def dump_lockedsigs(self):
-bb.plain(Writing locked sigs to + os.getcwd() + /locked-sigs.inc)
+def dump_lockedsigs(self, path=os.getcwd()):
+outfile = os.path.join(path, locked-sigs.inc)
+bb.plain(Writing locked sigs to %s % outfile)
types = {}
for k in self.runtaskdeps:
fn = k.rsplit(.,1)[0]
@@ -140,7 +141,7 @@ class
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
types[t] = []
types[t].append(k)
-with open(locked-sigs.inc, w) as f:
+with open(outfile, w) as f:
for t in types:
f.write('SIGGEN_LOCKEDSIGS_%s = \\\n' % t)
types[t].sort()
--
1.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Patchwork cleanup
Hi, I've started running the patchwork post-receive hook manually and marking as submitted many patches in the queue, but as there's 132 patches of patches still (down from 140-odd!) in an attempt to restore sanity to the oe-core I think we should just mark as obsolete every patch that was submitted before a cutoff date, say 1st January 2014. Any thoughts? As much as I'd love to ensure we didn't drop an excellent patch from 2012, I'm not going to manually check all the patches that the tool can't find automatically... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Patchwork cleanup
On Wed, Sep 10, 2014 at 12:12 PM, Burton, Ross ross.bur...@intel.com wrote: I've started running the patchwork post-receive hook manually and marking as submitted many patches in the queue, but as there's 132 patches of patches still (down from 140-odd!) in an attempt to restore sanity to the oe-core I think we should just mark as obsolete every patch that was submitted before a cutoff date, say 1st January 2014. Any thoughts? As much as I'd love to ensure we didn't drop an excellent patch from 2012, I'm not going to manually check all the patches that the tool can't find automatically... I think its ok. Thanks for doing it. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Patchwork cleanup
On 10 September 2014 21:21, Khem Raj raj.k...@gmail.com wrote: On Wed, Sep 10, 2014 at 12:12 PM, Burton, Ross ross.bur...@intel.com wrote: I've started running the patchwork post-receive hook manually and marking as submitted many patches in the queue, but as there's 132 patches of patches still (down from 140-odd!) in an attempt to restore sanity to the oe-core I think we should just mark as obsolete every patch that was submitted before a cutoff date, say 1st January 2014. Any thoughts? As much as I'd love to ensure we didn't drop an excellent patch from 2012, I'm not going to manually check all the patches that the tool can't find automatically... I think its ok. Thanks for doing it. As you have access to the server, do you think you could do this with a carefully crafted bit of SQL directly to the database? The alternative would be to find the patch ID that corresponds to a year ago and edit the state of every ID below that, which might take some time... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] texinfo: integrate texinfo 4.8
From: Roy Li rongqing...@windriver.com
It is a GPLv2 package
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../texinfo/texinfo-4.8/check-locale-h.patch | 28 ++
.../texinfo-4.8/do-compile-native-tools.patch | 49 +
.../texinfo-4.8/using-native-makeinfo.patch| 24 +
meta/recipes-extended/texinfo/texinfo_4.8.bb | 56
4 files changed, 157 insertions(+)
create mode 100644
meta/recipes-extended/texinfo/texinfo-4.8/check-locale-h.patch
create mode 100644
meta/recipes-extended/texinfo/texinfo-4.8/do-compile-native-tools.patch
create mode 100644
meta/recipes-extended/texinfo/texinfo-4.8/using-native-makeinfo.patch
create mode 100644 meta/recipes-extended/texinfo/texinfo_4.8.bb
diff --git a/meta/recipes-extended/texinfo/texinfo-4.8/check-locale-h.patch
b/meta/recipes-extended/texinfo/texinfo-4.8/check-locale-h.patch
new file mode 100644
index 000..4a8cc57
--- /dev/null
+++ b/meta/recipes-extended/texinfo/texinfo-4.8/check-locale-h.patch
@@ -0,0 +1,28 @@
+fix the macro check
+
+Upstream-status: Pending
+
+configure does not check if locale.h exists, but check setlocale,
+if setlocale exist, the locale.h should exist.
+
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ lib/system.h |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/system.h b/lib/system.h
+index 946eb3c..c70037b 100644
+--- a/lib/system.h
b/lib/system.h
+@@ -42,7 +42,7 @@ extern char *substring (const char *, const char *);
+ #include ctype.h
+
+ /* All systems nowadays probably have these functions, but ... */
+-#ifdef HAVE_LOCALE_H
++#ifdef HAVE_SETLOCALE
+ #include locale.h
+ #endif
+ #ifndef HAVE_SETLOCALE
+--
+1.7.10.4
+
diff --git
a/meta/recipes-extended/texinfo/texinfo-4.8/do-compile-native-tools.patch
b/meta/recipes-extended/texinfo/texinfo-4.8/do-compile-native-tools.patch
new file mode 100644
index 000..2cc5fbb
--- /dev/null
+++ b/meta/recipes-extended/texinfo/texinfo-4.8/do-compile-native-tools.patch
@@ -0,0 +1,49 @@
+From 458e9450cecf703f55536e609365162719585900 Mon Sep 17 00:00:00 2001
+From: Roy.Li rongqing...@windriver.com
+Date: Wed, 10 Sep 2014 17:03:29 +0800
+Subject: [PATCH] do not compile host tools, since we have native
+
+Upstream-status: Pending
+
+Signed-off-by: Roy.Li rongqing...@windriver.com
+---
+ configure.ac | 23 +--
+ 1 file changed, 1 insertion(+), 22 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index b46130d..cf58654 100644
+--- a/configure.ac
b/configure.ac
+@@ -90,28 +90,7 @@ AC_CANONICAL_BUILD
+ # $native_tools is also added to SUBDIRS in the main Makefile.am,
+ # so that make compiles the native tools first.
+ #
+-if test $cross_compiling = no; then
+- native_tools=
+-else
+- native_tools=tools
+- test -d $native_tools || mkdir $native_tools
+- confdir=`(cd $srcdir;pwd)`
+- # Make sure the secondary configure won't fail with
+- # error: source directory already configured.
+- rm -f config.status
+- AC_MSG_NOTICE([[Doing configure of native tools (${build}).]])
+- cd $native_tools || exit 1
+- # Run secondary configure in alternate environment or
+- # it gets the wrong CC etc. env -i gives this build host configure
+- # a clean environment.
+- env -i CC=${BUILD_CC} AR=${BUILD_AR} RANLIB=${BUILD_RANLIB} \
+- PATH=${PATH} \
+- tools_only=1 \
+-${confdir}/configure --build=${build} --host=${build} \
+- --disable-rpath --disable-nls
+- cd .. || exit 1
+- AC_MSG_NOTICE([[Continuing with main configure (${host}).]])
+-fi
++native_tools=
+ AC_SUBST(native_tools)
+ AM_CONDITIONAL(TOOLS_ONLY, [[test x$tools_only = x1]])
+
+--
+1.9.1
+
diff --git
a/meta/recipes-extended/texinfo/texinfo-4.8/using-native-makeinfo.patch
b/meta/recipes-extended/texinfo/texinfo-4.8/using-native-makeinfo.patch
new file mode 100644
index 000..d9bed69
--- /dev/null
+++ b/meta/recipes-extended/texinfo/texinfo-4.8/using-native-makeinfo.patch
@@ -0,0 +1,24 @@
+From 9b0df7d6d3c18cfac82c291d60a5357d1bc8d9d0 Mon Sep 17 00:00:00 2001
+From: Roy.Li rongqing...@windriver.com
+Date: Wed, 10 Sep 2014 17:10:03 +0800
+Subject: [PATCH] using native makeinfo
+
+Upstream-status: Pending
+
+Signed-off-by: Roy.Li rongqing...@windriver.com
+---
+ doc/Makefile.am| 2 +-
+
+diff --git a/doc/Makefile.am b/doc/Makefile.am
+index 63df818..b6ceb34 100644
+--- a/doc/Makefile.am
b/doc/Makefile.am
+@@ -19,7 +19,7 @@ man_MANS = info.1 infokey.1 install-info.1 makeinfo.1
texindex.1 texi2dvi.1 \
+
+ # Use the programs built in our distribution, taking account of possible
+ # cross-compiling.
+-MAKEINFO = $(top_builddir)/$(native_tools)/makeinfo/makeinfo
++MAKEINFO = makeinfo
+ INSTALL_INFO = $(top_builddir)/$(native_tools)/util/install-info
+
+ TXI_XLATE = txi-cs.tex txi-de.tex txi-en.tex txi-es.tex txi-fr.tex \
diff --git a/meta/recipes-extended/texinfo/texinfo_4.8.bb
Re: [OE-core] [[PATCH] qemuppc64: add machine
On 09/09/2014 01:05 AM, Richard Purdie wrote: On Mon, 2014-09-08 at 18:53 -0700, Armin Kuster wrote: override USER_CLASSES as prelink does not currently work on ppc64 --- meta/conf/machine/qemuppc64.conf | 16 1 file changed, 16 insertions(+) create mode 100644 meta/conf/machine/qemuppc64.conf diff --git a/meta/conf/machine/qemuppc64.conf b/meta/conf/machine/qemuppc64.conf new file mode 100644 index 000..86916e5 --- /dev/null +++ b/meta/conf/machine/qemuppc64.conf @@ -0,0 +1,16 @@ +#@TYPE: Machine +#@NAME: qemu PPC 64 Emulator setup +#@DESCRIPTION: Machine configuration for running an PPC system under qemu emulation + +require conf/machine/include/qemu.inc +DEFAULTTUNE ?= ppc64p6 +require conf/machine/include/tune-power6.inc + +#prelink broken +USER_CLASSES = buildstats image-mklibs This is horrible. Can we somehow blacklist qemuppc64 in the prelink class itself? USER_CLASSES_remove = prelink That does not work nor does USER_CLASSES_remove = image-prelink image-prelink is removed from the variable but pre-linking is still affecting the image. bitbake -e | grep ^USER_CLASSES USER_CLASSES=buildstats image-mklibs I noticed that IMAGE_PREPROCESS_COMMAND variable has prelink in it. bitbake -e | grep ^IMAGE_PREPROCESS_COMMAND IMAGE_PREPROCESS_COMMAND= mklibs_optimize_image; prelink_image; If I override USER_CLASSES like above, then pre-link is not present in either variable. you really want me to fix the prelinking on ppc64 ;) If anyone has any pointers on where to look, let me know. - Armin would be better than overriding the users choice like above... Cheers, Richard +KERNEL_IMAGETYPE = vmlinux + +IMAGE_FSTYPES = ext2 ext3 + +SERIAL_CONSOLE ?= ttyS0 -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xserver-xorg: remove aarch64.patch
Patch aarch64.patch adds aarch64 support for xserver-xorg 1.13.1 in header file servermd.h. And aarch64 is supported in version 1.15.1 already and the patch causes redefine error. So remove aarch64.patch. Signed-off-by: Kai Kang kai.k...@windriver.com --- .../xorg-xserver/xserver-xorg/aarch64.patch| 35 -- .../xorg-xserver/xserver-xorg_1.15.1.bb| 1 - 2 files changed, 36 deletions(-) delete mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xorg/aarch64.patch diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg/aarch64.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/aarch64.patch deleted file mode 100644 index 045e24a..000 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg/aarch64.patch +++ /dev/null @@ -1,35 +0,0 @@ -Subject: Add AArch64 support to xserver-xorg -Author: Marcin Juszkiewicz marcin.juszkiew...@linaro.org - -lnx_video.c parts are not existing in 1.14 branch. - -Xserver was checked in AArch64 fastmodel (commercial one with graphics support). - -http://patchwork.freedesktop.org/patch/12785/ - -Upstream-Status: Pending - - include/servermd.h |7 +++ - 1 files changed, 7 insertions(+), 0 deletions(-) - xorg-server-1.13.1.orig/include/servermd.h -+++ xorg-server-1.13.1/include/servermd.h -@@ -243,10 +243,17 @@ SOFTWARE. - #define BITMAP_BIT_ORDER LSBFirst - #define GLYPHPADBYTES 4 - /* */ - #endif /* AMD64 */ - -+#if defined(__aarch64__) || defined(aarch64) || defined(__aarch64) -+#define IMAGE_BYTE_ORDER MSBFirst -+#define BITMAP_BIT_ORDER MSBFirst -+#define GLYPHPADBYTES 4 -+/* */ -+#endif /* AArch64 */ -+ - #if defined(SVR4) (defined(__i386__) || defined(__i386) ) || \ - defined(__alpha__) || defined(__alpha) || \ - defined(__i386__) || \ - defined(__s390x__) || defined(__s390__) - diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.1.bb index 22ac604..e952e60 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.1.bb +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.1.bb @@ -4,7 +4,6 @@ require xserver-xorg.inc SRC_URI += file://crosscompile.patch \ file://fix_open_max_preprocessor_error.patch \ file://mips64-compiler.patch \ -file://aarch64.patch \ file://xorg-CVE-2013-6424.patch \ file://xshmfence-option.patch \ -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
