* [PATCH 0/1] kernel: restore scripts in the sysroot @ 2013-10-08 21:12 Bruce Ashfield 2013-10-08 21:12 ` [PATCH 1/1] " Bruce Ashfield 0 siblings, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-10-08 21:12 UTC (permalink / raw) To: richard.purdie; +Cc: openembedded-core Richard/Saul, 3rd time is a charm, and I finally have the right incantation to build the scripts in: tmp/sysroots/<machine>/usr/src/kernel/scripts/mod This works in my environment, for my test cases, but I don't have Khem's exact external module build case handy. Khem: if you can try this patch and ack it if it works, that would be fantastic. Cheers, Bruce p.s. I'm out of the office for the next week, but will track this via my gmail account. The following changes since commit 72ca7801f3b733f7fc63326c1d8c98a3c32a519f: linux-yocto/3.10: integrate lxc kernel feature and 32 bit x86 config (2013-10-08 16:44:54 -0400) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel-oe http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe Bruce Ashfield (1): kernel: restore scripts in the sysroot meta/classes/kernel.bbclass | 11 +++++++++++ 1 file changed, 11 insertions(+) -- 1.8.1.2 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-08 21:12 [PATCH 0/1] kernel: restore scripts in the sysroot Bruce Ashfield @ 2013-10-08 21:12 ` Bruce Ashfield 2013-11-19 17:37 ` Mike Crowe 0 siblings, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-10-08 21:12 UTC (permalink / raw) To: richard.purdie; +Cc: openembedded-core When building against the sysroot, out of tree modules can require modpost and other utilities normally found in the kernel's scripts directory. For the kernel source in the staging dir, these scripts have been removed to avoid mixing archiectures when packaging kernel-dev (among other things). Rather than further complicate the kernel's install rule, or its packaging, we can restore the scripts by building them in the kernel staging directory after the sstate is installed, making them available to packages that need them. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> --- meta/classes/kernel.bbclass | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 4acfb7e..d5fa801 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -292,6 +292,17 @@ kernel_do_install() { } do_install[prefuncs] += "package_get_auto_pr" + +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" +kernelscripts_sstate_postinst () { + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then + ( + cd ${STAGING_KERNEL_DIR} + oe_runmake scripts + ) + fi +} + sysroot_stage_all_append() { sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} } -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-08 21:12 ` [PATCH 1/1] " Bruce Ashfield @ 2013-11-19 17:37 ` Mike Crowe 2013-11-19 17:37 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Mike Crowe 2013-11-19 17:46 ` [PATCH 1/1] kernel: restore scripts in the sysroot Phil Blundell 0 siblings, 2 replies; 37+ messages in thread From: Mike Crowe @ 2013-11-19 17:37 UTC (permalink / raw) To: openembedded-core On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote: > When building against the sysroot, out of tree modules can require modpost > and other utilities normally found in the kernel's scripts directory. For > the kernel source in the staging dir, these scripts have been removed to > avoid mixing archiectures when packaging kernel-dev (among other things). > > Rather than further complicate the kernel's install rule, or its packaging, > we can restore the scripts by building them in the kernel staging directory > after the sstate is installed, making them available to packages that need them. > > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> > --- > meta/classes/kernel.bbclass | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 4acfb7e..d5fa801 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -292,6 +292,17 @@ kernel_do_install() { > } > do_install[prefuncs] += "package_get_auto_pr" > > + > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" > +kernelscripts_sstate_postinst () { > + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then > + ( > + cd ${STAGING_KERNEL_DIR} > + oe_runmake scripts > + ) > + fi > +} > + > sysroot_stage_all_append() { > sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} > } This sstate_postinst fails for me when the compiler isn't already present in the sysroot. Also, I notice that the environment and parameters passed to oe_runmake are not the same as those used by kernel_do_compile etc. Patches to follow. Mike. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene 2013-11-19 17:37 ` Mike Crowe @ 2013-11-19 17:37 ` Mike Crowe 2013-11-19 17:37 ` [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst Mike Crowe 2013-11-19 17:47 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Bruce Ashfield 2013-11-19 17:46 ` [PATCH 1/1] kernel: restore scripts in the sysroot Phil Blundell 1 sibling, 2 replies; 37+ messages in thread From: Mike Crowe @ 2013-11-19 17:37 UTC (permalink / raw) To: openembedded-core; +Cc: Mike Crowe kernelscripts_sstate_postinst uses the compiler (and therefore binutils) to generate the kernel scripts so it must declare a dependency on them. The ones in DEPENDS don't apply to do_populate_sysroot_setscene. Signed-off-by: Mike Crowe <mac@mcrowe.com> --- meta/classes/kernel.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 6959aa1..2fad6e0 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -312,6 +312,8 @@ kernelscripts_sstate_postinst () { fi } +do_populate_sysroot_setscene[depends] += "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot virtual/${TARGET_PREFIX}binutils:do_populate_sysroot" + python sysroot_stage_all () { oe.path.copyhardlinktree(d.expand("${D}${KERNEL_SRC_PATH}"), d.expand("${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}")) } -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst 2013-11-19 17:37 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Mike Crowe @ 2013-11-19 17:37 ` Mike Crowe 2013-11-19 17:41 ` Bruce Ashfield 2013-11-19 17:47 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Bruce Ashfield 1 sibling, 1 reply; 37+ messages in thread From: Mike Crowe @ 2013-11-19 17:37 UTC (permalink / raw) To: openembedded-core; +Cc: Mike Crowe Ensure that the environment variable and command line arguments that are used when calling make in kernel_do_compile are used in kernelscripts_sstate_postinst. Signed-off-by: Mike Crowe <mac@mcrowe.com> --- meta/classes/kernel.bbclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 2fad6e0..9d922d6 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -304,10 +304,11 @@ do_install[prefuncs] += "package_get_auto_pr" SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" kernelscripts_sstate_postinst () { + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then ( cd ${STAGING_KERNEL_DIR} - oe_runmake scripts + oe_runmake scripts CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS} ) fi } -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst 2013-11-19 17:37 ` [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst Mike Crowe @ 2013-11-19 17:41 ` Bruce Ashfield 2013-11-19 17:46 ` Richard Purdie 2013-11-19 17:49 ` Mike Crowe 0 siblings, 2 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 17:41 UTC (permalink / raw) To: Mike Crowe; +Cc: Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe <mac@mcrowe.com> wrote: > Ensure that the environment variable and command line arguments that are > used when calling make in kernel_do_compile are used in > kernelscripts_sstate_postinst. What issue was this causing for you ? The scripts are native, and hence should just be using the build machines compiler, linker and don't need the kernel args. So I'm not convinced that we need this patch, without seeing a tangible issue that was triggered. Bruce > > Signed-off-by: Mike Crowe <mac@mcrowe.com> > --- > meta/classes/kernel.bbclass | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 2fad6e0..9d922d6 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -304,10 +304,11 @@ do_install[prefuncs] += "package_get_auto_pr" > > SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" > kernelscripts_sstate_postinst () { > + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE > if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then > ( > cd ${STAGING_KERNEL_DIR} > - oe_runmake scripts > + oe_runmake scripts CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS} > ) > fi > } > -- > 1.7.10.4 > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst 2013-11-19 17:41 ` Bruce Ashfield @ 2013-11-19 17:46 ` Richard Purdie 2013-11-19 17:56 ` Bruce Ashfield 2013-11-19 17:49 ` Mike Crowe 1 sibling, 1 reply; 37+ messages in thread From: Richard Purdie @ 2013-11-19 17:46 UTC (permalink / raw) To: Bruce Ashfield Cc: Mike Crowe, Patches and discussions about the oe-core layer On Tue, 2013-11-19 at 12:41 -0500, Bruce Ashfield wrote: > On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe <mac@mcrowe.com> wrote: > > Ensure that the environment variable and command line arguments that are > > used when calling make in kernel_do_compile are used in > > kernelscripts_sstate_postinst. > > What issue was this causing for you ? The scripts are native, and hence > should just be using the build machines compiler, linker and don't need > the kernel args. > > So I'm not convinced that we need this patch, without seeing a tangible > issue that was triggered. I think for some arches at least, something targetish is being cleaned and then needing to be rebuilt. I don't want to have to add dependencies for the toolchain so we need to look into this further. Mike: which arch was this on and do you have the compile error? Cheers, Richard ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst 2013-11-19 17:46 ` Richard Purdie @ 2013-11-19 17:56 ` Bruce Ashfield 0 siblings, 0 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 17:56 UTC (permalink / raw) To: Richard Purdie Cc: Mike Crowe, Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 12:46 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-11-19 at 12:41 -0500, Bruce Ashfield wrote: >> On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe <mac@mcrowe.com> wrote: >> > Ensure that the environment variable and command line arguments that are >> > used when calling make in kernel_do_compile are used in >> > kernelscripts_sstate_postinst. >> >> What issue was this causing for you ? The scripts are native, and hence >> should just be using the build machines compiler, linker and don't need >> the kernel args. >> >> So I'm not convinced that we need this patch, without seeing a tangible >> issue that was triggered. > > I think for some arches at least, something targetish is being cleaned > and then needing to be rebuilt. Right. I suppose that if you are installing a mips->mips compiler, then the target toolchain is required. That really wasn't the intention of this change, so it likely isn't properly restricted to the native build case (Where native is a x86 development machine). But with Phil pointing out the module.bbclass 'make scripts' code again, I'd like to figure out why it wasn't working for the original bug report and try to drop all of this mess. Bruce > > I don't want to have to add dependencies for the toolchain so we need to > look into this further. > > Mike: which arch was this on and do you have the compile error? > > Cheers, > > Richard > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst 2013-11-19 17:41 ` Bruce Ashfield 2013-11-19 17:46 ` Richard Purdie @ 2013-11-19 17:49 ` Mike Crowe 2013-11-19 17:59 ` Phil Blundell 1 sibling, 1 reply; 37+ messages in thread From: Mike Crowe @ 2013-11-19 17:49 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer On Tuesday 19 November 2013 at 12:41:40 -0500, Bruce Ashfield wrote: > On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe <mac@mcrowe.com> wrote: > > Ensure that the environment variable and command line arguments that are > > used when calling make in kernel_do_compile are used in > > kernelscripts_sstate_postinst. > > What issue was this causing for you ? The scripts are native, and hence > should just be using the build machines compiler, linker and don't need > the kernel args. > > So I'm not convinced that we need this patch, without seeing a tangible > issue that was triggered. Well, for us v2.6.39 appears to be using the target compiler for something. At least, I get a lot of: DEBUG: Executing shell function kernelscripts_sstate_postinst NOTE: make scripts /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found make: mipsel-oe-linux-gcc: Command not found /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found which led me to the previous patch to ensure that the compiler is available. Thanks. Mike. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst 2013-11-19 17:49 ` Mike Crowe @ 2013-11-19 17:59 ` Phil Blundell 0 siblings, 0 replies; 37+ messages in thread From: Phil Blundell @ 2013-11-19 17:59 UTC (permalink / raw) To: Mike Crowe; +Cc: Patches and discussions about the oe-core layer On Tue, 2013-11-19 at 17:49 +0000, Mike Crowe wrote: > On Tuesday 19 November 2013 at 12:41:40 -0500, Bruce Ashfield wrote: > > What issue was this causing for you ? The scripts are native, and hence > > should just be using the build machines compiler, linker and don't need > > the kernel args. > > > > So I'm not convinced that we need this patch, without seeing a tangible > > issue that was triggered. > > Well, for us v2.6.39 appears to be using the target compiler for > something. At least, I get a lot of: I did "make V=1 scripts" in a kernel devshell and it seems to be using the cross-compiler to build scripts/mod/empty.o. It's not entirely obvious that this file actually needs to be in the sysroot, but it seems that patching the kernel to prevent it getting built would be a bit of a maintenance headache. p. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene 2013-11-19 17:37 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Mike Crowe 2013-11-19 17:37 ` [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst Mike Crowe @ 2013-11-19 17:47 ` Bruce Ashfield 1 sibling, 0 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 17:47 UTC (permalink / raw) To: Mike Crowe; +Cc: Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe <mac@mcrowe.com> wrote: > kernelscripts_sstate_postinst uses the compiler (and therefore binutils) to > generate the kernel scripts so it must declare a dependency on them. The > ones in DEPENDS don't apply to do_populate_sysroot_setscene. > > Signed-off-by: Mike Crowe <mac@mcrowe.com> > --- > meta/classes/kernel.bbclass | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 6959aa1..2fad6e0 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -312,6 +312,8 @@ kernelscripts_sstate_postinst () { > fi > } > > +do_populate_sysroot_setscene[depends] += "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot virtual/${TARGET_PREFIX}binutils:do_populate_sysroot" This makes sense, we have a bug about this that I was never able to reproduce: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5390 Bruce > + > python sysroot_stage_all () { > oe.path.copyhardlinktree(d.expand("${D}${KERNEL_SRC_PATH}"), d.expand("${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}")) > } > -- > 1.7.10.4 > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 17:37 ` Mike Crowe 2013-11-19 17:37 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Mike Crowe @ 2013-11-19 17:46 ` Phil Blundell 2013-11-19 17:54 ` Bruce Ashfield 1 sibling, 1 reply; 37+ messages in thread From: Phil Blundell @ 2013-11-19 17:46 UTC (permalink / raw) To: openembedded-core On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote: > On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote: > > When building against the sysroot, out of tree modules can require modpost > > and other utilities normally found in the kernel's scripts directory. For > > the kernel source in the staging dir, these scripts have been removed to > > avoid mixing archiectures when packaging kernel-dev (among other things). > > > > Rather than further complicate the kernel's install rule, or its packaging, > > we can restore the scripts by building them in the kernel staging directory > > after the sstate is installed, making them available to packages that need them. > > > > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> > > --- > > meta/classes/kernel.bbclass | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > > index 4acfb7e..d5fa801 100644 > > --- a/meta/classes/kernel.bbclass > > +++ b/meta/classes/kernel.bbclass > > @@ -292,6 +292,17 @@ kernel_do_install() { > > } > > do_install[prefuncs] += "package_get_auto_pr" > > > > + > > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" > > +kernelscripts_sstate_postinst () { > > + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then > > + ( > > + cd ${STAGING_KERNEL_DIR} > > + oe_runmake scripts > > + ) > > + fi > > +} > > + > > sysroot_stage_all_append() { > > sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} > > } > > This sstate_postinst fails for me when the compiler isn't already present > in the sysroot. > > Also, I notice that the environment and parameters passed to oe_runmake are > not the same as those used by kernel_do_compile etc. Also note that module.bbclass already does "make scripts" before do_compile() so out-of-tree modules should already have access to all the files that they need. If we're going to make a policy decision that the kernel is responsible for making scripts then I guess that's fine (modulo the implementation problems that Mike describes) but in that case the code in module{-base}.bbclass is redundant and ought to be removed. p. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 17:46 ` [PATCH 1/1] kernel: restore scripts in the sysroot Phil Blundell @ 2013-11-19 17:54 ` Bruce Ashfield 2013-11-19 18:17 ` Bruce Ashfield 0 siblings, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 17:54 UTC (permalink / raw) To: Phil Blundell; +Cc: Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote: > On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote: >> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote: >> > When building against the sysroot, out of tree modules can require modpost >> > and other utilities normally found in the kernel's scripts directory. For >> > the kernel source in the staging dir, these scripts have been removed to >> > avoid mixing archiectures when packaging kernel-dev (among other things). >> > >> > Rather than further complicate the kernel's install rule, or its packaging, >> > we can restore the scripts by building them in the kernel staging directory >> > after the sstate is installed, making them available to packages that need them. >> > >> > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> >> > --- >> > meta/classes/kernel.bbclass | 11 +++++++++++ >> > 1 file changed, 11 insertions(+) >> > >> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >> > index 4acfb7e..d5fa801 100644 >> > --- a/meta/classes/kernel.bbclass >> > +++ b/meta/classes/kernel.bbclass >> > @@ -292,6 +292,17 @@ kernel_do_install() { >> > } >> > do_install[prefuncs] += "package_get_auto_pr" >> > >> > + >> > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" >> > +kernelscripts_sstate_postinst () { >> > + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then >> > + ( >> > + cd ${STAGING_KERNEL_DIR} >> > + oe_runmake scripts >> > + ) >> > + fi >> > +} >> > + >> > sysroot_stage_all_append() { >> > sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} >> > } >> >> This sstate_postinst fails for me when the compiler isn't already present >> in the sysroot. >> >> Also, I notice that the environment and parameters passed to oe_runmake are >> not the same as those used by kernel_do_compile etc. > > Also note that module.bbclass already does "make scripts" before > do_compile() so out-of-tree modules should already have access to all > the files that they need. Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines. Khem was building out of the sysroot and the support scripts weren't present, something which we were able to consistently reproduce. Perhaps the whole problem was just a misordering of the tasks. I'll take another look. But yes, we need one way or the other .. not both. I'd prefer to not fiddle with sstate, so I'll go back and see why the module.bbclass code wasn't working for the reported error. Bruce > > If we're going to make a policy decision that the kernel is responsible > for making scripts then I guess that's fine (modulo the implementation > problems that Mike describes) but in that case the code in > module{-base}.bbclass is redundant and ought to be removed. > > p. > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 17:54 ` Bruce Ashfield @ 2013-11-19 18:17 ` Bruce Ashfield 2013-11-19 22:29 ` Khem Raj 0 siblings, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 18:17 UTC (permalink / raw) To: Phil Blundell; +Cc: Patches and discussions about the oe-core layer Adding Khem. Khem .. see below. On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote: >> On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote: >>> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote: >>> > When building against the sysroot, out of tree modules can require modpost >>> > and other utilities normally found in the kernel's scripts directory. For >>> > the kernel source in the staging dir, these scripts have been removed to >>> > avoid mixing archiectures when packaging kernel-dev (among other things). >>> > >>> > Rather than further complicate the kernel's install rule, or its packaging, >>> > we can restore the scripts by building them in the kernel staging directory >>> > after the sstate is installed, making them available to packages that need them. >>> > >>> > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> >>> > --- >>> > meta/classes/kernel.bbclass | 11 +++++++++++ >>> > 1 file changed, 11 insertions(+) >>> > >>> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >>> > index 4acfb7e..d5fa801 100644 >>> > --- a/meta/classes/kernel.bbclass >>> > +++ b/meta/classes/kernel.bbclass >>> > @@ -292,6 +292,17 @@ kernel_do_install() { >>> > } >>> > do_install[prefuncs] += "package_get_auto_pr" >>> > >>> > + >>> > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" >>> > +kernelscripts_sstate_postinst () { >>> > + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then >>> > + ( >>> > + cd ${STAGING_KERNEL_DIR} >>> > + oe_runmake scripts >>> > + ) >>> > + fi >>> > +} >>> > + >>> > sysroot_stage_all_append() { >>> > sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} >>> > } >>> >>> This sstate_postinst fails for me when the compiler isn't already present >>> in the sysroot. >>> >>> Also, I notice that the environment and parameters passed to oe_runmake are >>> not the same as those used by kernel_do_compile etc. >> >> Also note that module.bbclass already does "make scripts" before >> do_compile() so out-of-tree modules should already have access to all >> the files that they need. > > Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines. > Khem was building out of the sysroot and the support scripts weren't present, > something which we were able to consistently reproduce. > > Perhaps the whole problem was just a misordering of the tasks. I'll take another > look. > > But yes, we need one way or the other .. not both. I'd prefer to not fiddle with > sstate, so I'll go back and see why the module.bbclass code wasn't working > for the reported error. Khem: I wasn't working from a bugzilla when making these changes, so I can't find your original reproducer for the missing recordmcount script. Do you recall what it was ? I'm revisiting this and would like to understand why the make scripts in module-base.bbclass wasn't properly restoring the support scripts for your build. I'm leaning towards reverting the whole mess, but without the reproducing case, I can't be sure that I'm not breaking you again. Bruce > > Bruce > > >> >> If we're going to make a policy decision that the kernel is responsible >> for making scripts then I guess that's fine (modulo the implementation >> problems that Mike describes) but in that case the code in >> module{-base}.bbclass is redundant and ought to be removed. >> >> p. >> >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end" -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 18:17 ` Bruce Ashfield @ 2013-11-19 22:29 ` Khem Raj 2013-11-19 22:36 ` Richard Purdie ` (2 more replies) 0 siblings, 3 replies; 37+ messages in thread From: Khem Raj @ 2013-11-19 22:29 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer On Nov 19, 2013, at 10:17 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > Adding Khem. > > Khem .. see below. > > On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield > <bruce.ashfield@gmail.com> wrote: >> On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote: >>> On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote: >>>> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote: >>>>> When building against the sysroot, out of tree modules can require modpost >>>>> and other utilities normally found in the kernel's scripts directory. For >>>>> the kernel source in the staging dir, these scripts have been removed to >>>>> avoid mixing archiectures when packaging kernel-dev (among other things). >>>>> >>>>> Rather than further complicate the kernel's install rule, or its packaging, >>>>> we can restore the scripts by building them in the kernel staging directory >>>>> after the sstate is installed, making them available to packages that need them. >>>>> >>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> >>>>> --- >>>>> meta/classes/kernel.bbclass | 11 +++++++++++ >>>>> 1 file changed, 11 insertions(+) >>>>> >>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >>>>> index 4acfb7e..d5fa801 100644 >>>>> --- a/meta/classes/kernel.bbclass >>>>> +++ b/meta/classes/kernel.bbclass >>>>> @@ -292,6 +292,17 @@ kernel_do_install() { >>>>> } >>>>> do_install[prefuncs] += "package_get_auto_pr" >>>>> >>>>> + >>>>> +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" >>>>> +kernelscripts_sstate_postinst () { >>>>> + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then >>>>> + ( >>>>> + cd ${STAGING_KERNEL_DIR} >>>>> + oe_runmake scripts >>>>> + ) >>>>> + fi >>>>> +} >>>>> + >>>>> sysroot_stage_all_append() { >>>>> sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} >>>>> } >>>> >>>> This sstate_postinst fails for me when the compiler isn't already present >>>> in the sysroot. >>>> >>>> Also, I notice that the environment and parameters passed to oe_runmake are >>>> not the same as those used by kernel_do_compile etc. >>> >>> Also note that module.bbclass already does "make scripts" before >>> do_compile() so out-of-tree modules should already have access to all >>> the files that they need. >> >> Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines. >> Khem was building out of the sysroot and the support scripts weren't present, >> something which we were able to consistently reproduce. >> >> Perhaps the whole problem was just a misordering of the tasks. I'll take another >> look. >> >> But yes, we need one way or the other .. not both. I'd prefer to not fiddle with >> sstate, so I'll go back and see why the module.bbclass code wasn't working >> for the reported error. > > Khem: I wasn't working from a bugzilla when making these changes, so I > can't find your original reproducer for the missing recordmcount script. > > Do you recall what it was ? I'm revisiting this and would like to understand > why the make scripts in module-base.bbclass wasn't properly restoring > the support scripts for your build. > > I'm leaning towards reverting the whole mess, but without the reproducing > case, I can't be sure that I'm not breaking you again. Well reproducer case is that build from sstate but such that an external module needs to be rebuilt if external module also comes from sstate then it all is fine. Its only when everything is coming from sstate except this external module which needs to be rebuilt then you see this problem. now, I see the code in module-base.class # # Ensure the hostprogs are available for module compilation. Modules that # inherit this recipe and override do_compile() should be sure to call # do_make_scripts() or ensure the scripts are built independently. # do_make_scripts() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ -C ${STAGING_KERNEL_DIR} scripts } so it expects that, do_make_scripts is explicitly called by external module recipes and my recipes did override module_do_compile task but not do_compile like below module_do_compile() { oe_runmake } so, is comment wrong there should it say module_do_compile instead ? will it work with sstate always ? it will be OK to revert it if thats the case. > > Bruce > >> >> Bruce >> >> >>> >>> If we're going to make a policy decision that the kernel is responsible >>> for making scripts then I guess that's fine (modulo the implementation >>> problems that Mike describes) but in that case the code in >>> module{-base}.bbclass is redundant and ought to be removed. >>> >>> p. >>> >>> >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> >> >> >> -- >> "Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end" > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:29 ` Khem Raj @ 2013-11-19 22:36 ` Richard Purdie 2013-11-19 22:39 ` Khem Raj 2013-11-19 22:37 ` Bruce Ashfield 2013-11-19 23:41 ` Phil Blundell 2 siblings, 1 reply; 37+ messages in thread From: Richard Purdie @ 2013-11-19 22:36 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote: > Well reproducer case is that build from sstate but such that an external module needs to be rebuilt > if external module also comes from sstate then it all is fine. Its only when everything is coming from > sstate except this external module which needs to be rebuilt then you see this problem. > > now, I see the code in module-base.class > > # > # Ensure the hostprogs are available for module compilation. Modules that > # inherit this recipe and override do_compile() should be sure to call > # do_make_scripts() or ensure the scripts are built independently. > # > do_make_scripts() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ > -C ${STAGING_KERNEL_DIR} scripts > } > > so it expects that, do_make_scripts is explicitly called by external module recipes > > and my recipes did override module_do_compile task but not do_compile like below > > module_do_compile() { > oe_runmake > } > > so, is comment wrong there should it say module_do_compile instead ? > > will it work with sstate always ? > > it will be OK to revert it if thats the case. Did you inherit module-base or module? I think the wording applies to module and not module-base. I think the function used to be in module and was moved along with the comment which is now incorrect. Cheers, Richard ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:36 ` Richard Purdie @ 2013-11-19 22:39 ` Khem Raj 2013-11-19 22:45 ` Richard Purdie 0 siblings, 1 reply; 37+ messages in thread From: Khem Raj @ 2013-11-19 22:39 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote: > >> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt >> if external module also comes from sstate then it all is fine. Its only when everything is coming from >> sstate except this external module which needs to be rebuilt then you see this problem. >> >> now, I see the code in module-base.class >> >> # >> # Ensure the hostprogs are available for module compilation. Modules that >> # inherit this recipe and override do_compile() should be sure to call >> # do_make_scripts() or ensure the scripts are built independently. >> # >> do_make_scripts() { >> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >> make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ >> -C ${STAGING_KERNEL_DIR} scripts >> } >> >> so it expects that, do_make_scripts is explicitly called by external module recipes >> >> and my recipes did override module_do_compile task but not do_compile like below >> >> module_do_compile() { >> oe_runmake >> } >> >> so, is comment wrong there should it say module_do_compile instead ? >> >> will it work with sstate always ? >> >> it will be OK to revert it if thats the case. > > Did you inherit module-base or module? I think the wording applies to > module and not module-base. I think the function used to be in module > and was moved along with the comment which is now incorrect. > inherit module > Cheers, > > Richard > > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:39 ` Khem Raj @ 2013-11-19 22:45 ` Richard Purdie 2013-11-20 2:59 ` Khem Raj 0 siblings, 1 reply; 37+ messages in thread From: Richard Purdie @ 2013-11-19 22:45 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote: > On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > > On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote: > > > >> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt > >> if external module also comes from sstate then it all is fine. Its only when everything is coming from > >> sstate except this external module which needs to be rebuilt then you see this problem. > >> > >> now, I see the code in module-base.class > >> > >> # > >> # Ensure the hostprogs are available for module compilation. Modules that > >> # inherit this recipe and override do_compile() should be sure to call > >> # do_make_scripts() or ensure the scripts are built independently. > >> # > >> do_make_scripts() { > >> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > >> make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ > >> -C ${STAGING_KERNEL_DIR} scripts > >> } > >> > >> so it expects that, do_make_scripts is explicitly called by external module recipes > >> > >> and my recipes did override module_do_compile task but not do_compile like below > >> > >> module_do_compile() { > >> oe_runmake > >> } > >> > >> so, is comment wrong there should it say module_do_compile instead ? > >> > >> will it work with sstate always ? > >> > >> it will be OK to revert it if thats the case. > > > > Did you inherit module-base or module? I think the wording applies to > > module and not module-base. I think the function used to be in module > > and was moved along with the comment which is now incorrect. > > > > inherit module So in that case there is: addtask make_scripts after do_patch before do_compile do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock" do_make_scripts[deptask] = "do_populate_sysroot" which forces the make_scripts task to run before compile. I don't see how that could therefore fail? :/ Do you have a copy of the exact log? I'm wondering if this is another variant of the bitbake dependency bug I just tracked down (http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118) Cheers, Richard ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:45 ` Richard Purdie @ 2013-11-20 2:59 ` Khem Raj 2013-11-20 4:43 ` Bruce Ashfield 0 siblings, 1 reply; 37+ messages in thread From: Khem Raj @ 2013-11-20 2:59 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On Nov 19, 2013, at 2:45 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote: >> On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: >> >>> On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote: >>> >>>> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt >>>> if external module also comes from sstate then it all is fine. Its only when everything is coming from >>>> sstate except this external module which needs to be rebuilt then you see this problem. >>>> >>>> now, I see the code in module-base.class >>>> >>>> # >>>> # Ensure the hostprogs are available for module compilation. Modules that >>>> # inherit this recipe and override do_compile() should be sure to call >>>> # do_make_scripts() or ensure the scripts are built independently. >>>> # >>>> do_make_scripts() { >>>> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >>>> make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ >>>> -C ${STAGING_KERNEL_DIR} scripts >>>> } >>>> >>>> so it expects that, do_make_scripts is explicitly called by external module recipes >>>> >>>> and my recipes did override module_do_compile task but not do_compile like below >>>> >>>> module_do_compile() { >>>> oe_runmake >>>> } >>>> >>>> so, is comment wrong there should it say module_do_compile instead ? >>>> >>>> will it work with sstate always ? >>>> >>>> it will be OK to revert it if thats the case. >>> >>> Did you inherit module-base or module? I think the wording applies to >>> module and not module-base. I think the function used to be in module >>> and was moved along with the comment which is now incorrect. >>> >> >> inherit module > > So in that case there is: > > addtask make_scripts after do_patch before do_compile > do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock" > do_make_scripts[deptask] = “do_populate_sysroot” > yes I see. > which forces the make_scripts task to run before compile. I don't see > how that could therefore fail? :/ > > Do you have a copy of the exact log? Not anymore, it was sometime ago, the logs are unfortunately recycled. > I'm wondering if this is another > variant of the bitbake dependency bug I just tracked down > (http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118) > ah very likely, I think I will try this fix and revert the kernel.bbclass fix locally and see if I still am able to reproduce this issue. In any case I think the kernel.bbclass may be abandoned since I now think it was a wrong fix although it did fix the problem > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-20 2:59 ` Khem Raj @ 2013-11-20 4:43 ` Bruce Ashfield 0 siblings, 0 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-11-20 4:43 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 9:59 PM, Khem Raj <raj.khem@gmail.com> wrote: > > On Nov 19, 2013, at 2:45 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > >> On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote: >>> On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: >>> >>>> On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote: >>>> >>>>> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt >>>>> if external module also comes from sstate then it all is fine. Its only when everything is coming from >>>>> sstate except this external module which needs to be rebuilt then you see this problem. >>>>> >>>>> now, I see the code in module-base.class >>>>> >>>>> # >>>>> # Ensure the hostprogs are available for module compilation. Modules that >>>>> # inherit this recipe and override do_compile() should be sure to call >>>>> # do_make_scripts() or ensure the scripts are built independently. >>>>> # >>>>> do_make_scripts() { >>>>> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >>>>> make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ >>>>> -C ${STAGING_KERNEL_DIR} scripts >>>>> } >>>>> >>>>> so it expects that, do_make_scripts is explicitly called by external module recipes >>>>> >>>>> and my recipes did override module_do_compile task but not do_compile like below >>>>> >>>>> module_do_compile() { >>>>> oe_runmake >>>>> } >>>>> >>>>> so, is comment wrong there should it say module_do_compile instead ? >>>>> >>>>> will it work with sstate always ? >>>>> >>>>> it will be OK to revert it if thats the case. >>>> >>>> Did you inherit module-base or module? I think the wording applies to >>>> module and not module-base. I think the function used to be in module >>>> and was moved along with the comment which is now incorrect. >>>> >>> >>> inherit module >> >> So in that case there is: >> >> addtask make_scripts after do_patch before do_compile >> do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock" >> do_make_scripts[deptask] = “do_populate_sysroot” >> > > yes I see. > > >> which forces the make_scripts task to run before compile. I don't see >> how that could therefore fail? :/ >> >> Do you have a copy of the exact log? > > Not anymore, it was sometime ago, the logs are unfortunately recycled. > >> I'm wondering if this is another >> variant of the bitbake dependency bug I just tracked down >> (http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118) >> > > ah very likely, I think I will try this fix and revert the kernel.bbclass fix locally and see if I still am > able to reproduce this issue. In any case I think the kernel.bbclass may be abandoned since I now think it > was a wrong fix although it did fix the problem > Agreed. Since you have control over your recipes, you don't have to worry about some of the more evil ones that build, and inside their own build head reference the kernel-staging tree and attempt to build modules. Just getting the right inheritance should fix it up. The other case is a different concern, and even then, including module, and overriding the do_compile() should work to get the scripts restored and not just attempt to launch a build. I'm going to be in Transit tomorrow, so won't be all that responsive, but my vote is now to simply revert the sstate scripts changes once Khem confirms that he is ok for his builds. Cheers, Bruce >> Cheers, >> >> Richard >> > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:29 ` Khem Raj 2013-11-19 22:36 ` Richard Purdie @ 2013-11-19 22:37 ` Bruce Ashfield 2013-11-19 22:42 ` Richard Purdie 2013-11-19 23:44 ` Phil Blundell 2013-11-19 23:41 ` Phil Blundell 2 siblings, 2 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 22:37 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 5:29 PM, Khem Raj <raj.khem@gmail.com> wrote: > > On Nov 19, 2013, at 10:17 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > >> Adding Khem. >> >> Khem .. see below. >> >> On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield >> <bruce.ashfield@gmail.com> wrote: >>> On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote: >>>> On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote: >>>>> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote: >>>>>> When building against the sysroot, out of tree modules can require modpost >>>>>> and other utilities normally found in the kernel's scripts directory. For >>>>>> the kernel source in the staging dir, these scripts have been removed to >>>>>> avoid mixing archiectures when packaging kernel-dev (among other things). >>>>>> >>>>>> Rather than further complicate the kernel's install rule, or its packaging, >>>>>> we can restore the scripts by building them in the kernel staging directory >>>>>> after the sstate is installed, making them available to packages that need them. >>>>>> >>>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> >>>>>> --- >>>>>> meta/classes/kernel.bbclass | 11 +++++++++++ >>>>>> 1 file changed, 11 insertions(+) >>>>>> >>>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >>>>>> index 4acfb7e..d5fa801 100644 >>>>>> --- a/meta/classes/kernel.bbclass >>>>>> +++ b/meta/classes/kernel.bbclass >>>>>> @@ -292,6 +292,17 @@ kernel_do_install() { >>>>>> } >>>>>> do_install[prefuncs] += "package_get_auto_pr" >>>>>> >>>>>> + >>>>>> +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" >>>>>> +kernelscripts_sstate_postinst () { >>>>>> + if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then >>>>>> + ( >>>>>> + cd ${STAGING_KERNEL_DIR} >>>>>> + oe_runmake scripts >>>>>> + ) >>>>>> + fi >>>>>> +} >>>>>> + >>>>>> sysroot_stage_all_append() { >>>>>> sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} >>>>>> } >>>>> >>>>> This sstate_postinst fails for me when the compiler isn't already present >>>>> in the sysroot. >>>>> >>>>> Also, I notice that the environment and parameters passed to oe_runmake are >>>>> not the same as those used by kernel_do_compile etc. >>>> >>>> Also note that module.bbclass already does "make scripts" before >>>> do_compile() so out-of-tree modules should already have access to all >>>> the files that they need. >>> >>> Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines. >>> Khem was building out of the sysroot and the support scripts weren't present, >>> something which we were able to consistently reproduce. >>> >>> Perhaps the whole problem was just a misordering of the tasks. I'll take another >>> look. >>> >>> But yes, we need one way or the other .. not both. I'd prefer to not fiddle with >>> sstate, so I'll go back and see why the module.bbclass code wasn't working >>> for the reported error. >> >> Khem: I wasn't working from a bugzilla when making these changes, so I >> can't find your original reproducer for the missing recordmcount script. >> >> Do you recall what it was ? I'm revisiting this and would like to understand >> why the make scripts in module-base.bbclass wasn't properly restoring >> the support scripts for your build. >> >> I'm leaning towards reverting the whole mess, but without the reproducing >> case, I can't be sure that I'm not breaking you again. > > Well reproducer case is that build from sstate but such that an external module needs to be rebuilt > if external module also comes from sstate then it all is fine. Its only when everything is coming from > sstate except this external module which needs to be rebuilt then you see this problem. > Right. > now, I see the code in module-base.class > > # > # Ensure the hostprogs are available for module compilation. Modules that > # inherit this recipe and override do_compile() should be sure to call > # do_make_scripts() or ensure the scripts are built independently. > # > do_make_scripts() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ > -C ${STAGING_KERNEL_DIR} scripts > } > > so it expects that, do_make_scripts is explicitly called by external module recipes > Exactly. And I had windriver bug with the same symptoms as yours. It was a package that built its own modules, and hence never called this either. > and my recipes did override module_do_compile task but not do_compile like below > > module_do_compile() { > oe_runmake > } > > so, is comment wrong there should it say module_do_compile instead ? > > will it work with sstate always ? > > it will be OK to revert it if thats the case. I'll come up with something that works in all cases. The sstate fix is better from the point of view that it is transparent to the recipes, and they don't need to do anything special for the support. So my proposal is this: - fix the new bug at hand by making the sstate change depend on the toolchain (I agree that patching the scripts to not reference the target toolchain isn't a good idea since not all kernels get the rix). - remove the modules-base.bbclass scripts recreation, so we only have one scripts restore in the tree. Alternatively, recipes need to be fixed to call the modules-base.bbclass routine to restore scripts, and I think it is obvious that won't work in all cases. I'll wait for comments/concensus before sending a new patch (which needs to be tested on all the cases), but in the meantime, the patches to the list to fix the sstate solution are good to be applied. Cheers, Bruce > >> >> Bruce >> >>> >>> Bruce >>> >>> >>>> >>>> If we're going to make a policy decision that the kernel is responsible >>>> for making scripts then I guess that's fine (modulo the implementation >>>> problems that Mike describes) but in that case the code in >>>> module{-base}.bbclass is redundant and ought to be removed. >>>> >>>> p. >>>> >>>> >>>> _______________________________________________ >>>> Openembedded-core mailing list >>>> Openembedded-core@lists.openembedded.org >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>> >>> >>> >>> -- >>> "Thou shalt not follow the NULL pointer, for chaos and madness await >>> thee at its end" >> >> >> >> -- >> "Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end" > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:37 ` Bruce Ashfield @ 2013-11-19 22:42 ` Richard Purdie 2013-11-19 22:46 ` Bruce Ashfield 2013-11-19 23:44 ` Phil Blundell 1 sibling, 1 reply; 37+ messages in thread From: Richard Purdie @ 2013-11-19 22:42 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote: > > Exactly. And I had windriver bug with the same symptoms as yours. It > was a package > that built its own modules, and hence never called this either. > > > and my recipes did override module_do_compile task but not do_compile like below > > > > module_do_compile() { > > oe_runmake > > } > > > > so, is comment wrong there should it say module_do_compile instead ? > > > > will it work with sstate always ? > > > > it will be OK to revert it if thats the case. > > I'll come up with something that works in all cases. The sstate fix is > better from the point > of view that it is transparent to the recipes, and they don't need to > do anything special > for the support. > > So my proposal is this: > > - fix the new bug at hand by making the sstate change depend on the > toolchain (I agree > that patching the scripts to not reference the target toolchain > isn't a good idea since not > all kernels get the rix). Can we please not do this? Adding in toolchain dependencies into the sstate code whilst possible, is going to massively complicate the dependency chains and is a last possible resort. I bought that argument in the useradd case since there are horrible issues there. We don't have that issue here. In kernel terms, its safer/easier to hack the kernel makefiles than expecting sstate to work well with dependencies like that embedded in it. > - remove the modules-base.bbclass scripts recreation, so we only have > one scripts > restore in the tree. > > Alternatively, recipes need to be fixed to call the > modules-base.bbclass routine to restore > scripts, and I think it is obvious that won't work in all cases. Which cases won't that work in? As far as I'm concerned, people using module-base are taking a loaded gun and are expected to use it safely (which means calling do_make_scripts somehow). People wanting a safer ride can use module which adds the appropriate task for them. The comments in the bbclass files do need fixing but that is trivial to sort out. > I'll wait for comments/concensus before sending a new patch (which > needs to be tested > on all the cases), but in the meantime, the patches to the list to fix > the sstate solution are good to be applied. I will respectfully disagree ;-). Cheers, Richard ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:42 ` Richard Purdie @ 2013-11-19 22:46 ` Bruce Ashfield 0 siblings, 0 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 22:46 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 5:42 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote: >> >> Exactly. And I had windriver bug with the same symptoms as yours. It >> was a package >> that built its own modules, and hence never called this either. >> >> > and my recipes did override module_do_compile task but not do_compile like below >> > >> > module_do_compile() { >> > oe_runmake >> > } >> > >> > so, is comment wrong there should it say module_do_compile instead ? >> > >> > will it work with sstate always ? >> > >> > it will be OK to revert it if thats the case. >> >> I'll come up with something that works in all cases. The sstate fix is >> better from the point >> of view that it is transparent to the recipes, and they don't need to >> do anything special >> for the support. >> >> So my proposal is this: >> >> - fix the new bug at hand by making the sstate change depend on the >> toolchain (I agree >> that patching the scripts to not reference the target toolchain >> isn't a good idea since not >> all kernels get the rix). > > Can we please not do this? Adding in toolchain dependencies into the > sstate code whilst possible, is going to massively complicate the > dependency chains and is a last possible resort. I bought that argument > in the useradd case since there are horrible issues there. We don't have > that issue here. > Works for me. I just wonder if there's another way to handle things more gracefully ? i.e. somehow check if the toolchain isn't available and warn, otherwise continue making the scripts ? > In kernel terms, its safer/easier to hack the kernel makefiles than > expecting sstate to work well with dependencies like that embedded in > it. It is pretty simple to make the change. Just making it available everywhere is the trick. > >> - remove the modules-base.bbclass scripts recreation, so we only have >> one scripts >> restore in the tree. >> >> Alternatively, recipes need to be fixed to call the >> modules-base.bbclass routine to restore >> scripts, and I think it is obvious that won't work in all cases. > > Which cases won't that work in? > > As far as I'm concerned, people using module-base are taking a loaded > gun and are expected to use it safely (which means calling > do_make_scripts somehow). People wanting a safer ride can use module > which adds the appropriate task for them. I've got people not using any of the above .. yes, I know they are evil too :) > > The comments in the bbclass files do need fixing but that is trivial to > sort out. > >> I'll wait for comments/concensus before sending a new patch (which >> needs to be tested >> on all the cases), but in the meantime, the patches to the list to fix >> the sstate solution are good to be applied. > > I will respectfully disagree ;-). No patch from me for this then. That's why i waited, I figured it wouldn't be immediate agreement. Bruce > > Cheers, > > Richard > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:37 ` Bruce Ashfield 2013-11-19 22:42 ` Richard Purdie @ 2013-11-19 23:44 ` Phil Blundell 2013-11-19 22:48 ` Bruce Ashfield 1 sibling, 1 reply; 37+ messages in thread From: Phil Blundell @ 2013-11-19 23:44 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote: > Alternatively, recipes need to be fixed to call the > modules-base.bbclass routine to restore > scripts, and I think it is obvious that won't work in all cases. Admittedly I'm no expert, but this is not obvious to me. Why can't those recipes just be fixed to do the right thing? p. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 23:44 ` Phil Blundell @ 2013-11-19 22:48 ` Bruce Ashfield 0 siblings, 0 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-11-19 22:48 UTC (permalink / raw) To: Phil Blundell; +Cc: Patches and discussions about the oe-core layer On Tue, Nov 19, 2013 at 6:44 PM, Phil Blundell <pb@pbcl.net> wrote: > On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote: >> Alternatively, recipes need to be fixed to call the >> modules-base.bbclass routine to restore >> scripts, and I think it is obvious that won't work in all cases. > > Admittedly I'm no expert, but this is not obvious to me. Why can't > those recipes just be fixed to do the right thing? Alas, people with legacy build environments that they've wrapped and ported to bitbake .. they either can't or won't change, so I'm stuck at least trying to detect them. That wasn't the primary driver for this though, if that case breaks, they'll live and so will i :) I think we are converging to removing the sstate scripts restore, which is fine with me a this point, as long as Khem isn't broken. Bruce > > p. > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-11-19 22:29 ` Khem Raj 2013-11-19 22:36 ` Richard Purdie 2013-11-19 22:37 ` Bruce Ashfield @ 2013-11-19 23:41 ` Phil Blundell 2 siblings, 0 replies; 37+ messages in thread From: Phil Blundell @ 2013-11-19 23:41 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote: > Well reproducer case is that build from sstate but such that an external module needs to be rebuilt > if external module also comes from sstate then it all is fine. Its only when everything is coming from > sstate except this external module which needs to be rebuilt then you see this problem. > > now, I see the code in module-base.class > > # > # Ensure the hostprogs are available for module compilation. Modules that > # inherit this recipe and override do_compile() should be sure to call > # do_make_scripts() or ensure the scripts are built independently. > # > do_make_scripts() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \ > -C ${STAGING_KERNEL_DIR} scripts > } > > so it expects that, do_make_scripts is explicitly called by external module recipes > > and my recipes did override module_do_compile task but not do_compile like below > > module_do_compile() { > oe_runmake > } > > so, is comment wrong there should it say module_do_compile instead ? The comment is slightly wrong, yes. For correct results you need to either: 1. inherit module (not module-base), which does: addtask make_scripts after do_patch before do_compile and will ensure that the scripts are built before your module is compiled without you needing to do anything else. Or... 2. inherit module-base and arrange to call do_make_scripts() explicitly from your own recipe. p. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 0/1] kernel: provide scripts in the sysroot @ 2013-10-04 0:02 Bruce Ashfield 2013-10-04 0:02 ` [PATCH 1/1] kernel: restore " Bruce Ashfield 0 siblings, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-10-04 0:02 UTC (permalink / raw) To: richard.purdie; +Cc: openembedded-core Richard/Saul, Khem noticed that he was seeing frequent "modpost missing" messages in his logs for out of tree builds. This is due to the missing kernel scripts, which we remove for packaging reasons. Rather than jiggle the kernel install rule itself, experience shows that just heading to the sysroot and re-creating the scripts is easy enough to do. [PATCH 1/1] kernel: restore scripts in the sysroot When building against the sysroot, out of tree modules can require modpost and other utilities normally found in the kernel's scripts directory. For the kernel source in the staging dir, these scripts have been removed to avoid mixing archiectures when packaging kernel-dev (among other things). Rather than further complicate the kernel's install rule, or its packaging, we can jump into the sysroot and restore the scripts by building them, hence making them available to packages that need them. Khem confirmed that the same fix worked for him. cc: Khem Raj <raj.khem@gmail.com> Cheers, Bruce The following changes since commit e7a20238dc73bb449f15feaf0dead51daf796184: maintainers: Add some maintainers (2013-10-03 10:22:30 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel-oe http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe Bruce Ashfield (1): kernel: restore scripts in the sysroot meta/classes/kernel.bbclass | 8 ++++++++ 1 file changed, 8 insertions(+) -- 1.8.1.2 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-04 0:02 [PATCH 0/1] kernel: provide " Bruce Ashfield @ 2013-10-04 0:02 ` Bruce Ashfield 2013-10-04 0:58 ` Khem Raj 2013-10-04 7:46 ` Richard Purdie 0 siblings, 2 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-10-04 0:02 UTC (permalink / raw) To: richard.purdie; +Cc: openembedded-core When building against the sysroot, out of tree modules can require modpost and other utilities normally found in the kernel's scripts directory. For the kernel source in the staging dir, these scripts have been removed to avoid mixing archiectures when packaging kernel-dev (among other things). Rather than further complicate the kernel's install rule, or its packaging, we can jump into the sysroot and restore the scripts by building them, hence making them available to packages that need them. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> --- meta/classes/kernel.bbclass | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 4acfb7e..d856e31 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -294,6 +294,14 @@ do_install[prefuncs] += "package_get_auto_pr" sysroot_stage_all_append() { sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} + + # Restore kernel scripts in the sysroot, since they had to be removed during + # packaging to avoid mismatched arch QA errors, but are required/useful when + # packages like out of tree kernel modules are built. Rather than playing QA + # games, it is easier to just do this work in the sysroot. + ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; + oe_runmake scripts + ) } kernel_do_configure() { -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-04 0:02 ` [PATCH 1/1] kernel: restore " Bruce Ashfield @ 2013-10-04 0:58 ` Khem Raj 2013-10-04 0:59 ` Bruce Ashfield 2013-10-04 7:46 ` Richard Purdie 1 sibling, 1 reply; 37+ messages in thread From: Khem Raj @ 2013-10-04 0:58 UTC (permalink / raw) To: Bruce Ashfield; +Cc: openembedded-core On Oct 3, 2013, at 5:02 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > When building against the sysroot, out of tree modules can require modpost > and other utilities normally found in the kernel's scripts directory. For > the kernel source in the staging dir, these scripts have been removed to > avoid mixing archiectures when packaging kernel-dev (among other things). > > Rather than further complicate the kernel's install rule, or its packaging, > we can jump into the sysroot and restore the scripts by building them, hence > making them available to packages that need them. > > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> > --- > meta/classes/kernel.bbclass | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 4acfb7e..d856e31 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -294,6 +294,14 @@ do_install[prefuncs] += "package_get_auto_pr" > > sysroot_stage_all_append() { > sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} > + > + # Restore kernel scripts in the sysroot, since they had to be removed during > + # packaging to avoid mismatched arch QA errors, but are required/useful when > + # packages like out of tree kernel modules are built. Rather than playing QA > + # games, it is easier to just do this work in the sysroot. > + ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; This was cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}/scripts in my patch but I will test out this one too. but this is ok since ifeq ($(KBUILD_EXTMOD),) # Additional helpers built in scripts/ # Carefully list dependencies so we do not try to build scripts twice # in parallel PHONY += scripts scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \ asm-generic $(Q)$(MAKE) $(build)=$(@) > + oe_runmake scripts > + ) > } > > kernel_do_configure() { > -- > 1.8.1.2 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-04 0:58 ` Khem Raj @ 2013-10-04 0:59 ` Bruce Ashfield 0 siblings, 0 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-10-04 0:59 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On 13-10-03 8:58 PM, Khem Raj wrote: > > On Oct 3, 2013, at 5:02 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > >> When building against the sysroot, out of tree modules can require modpost >> and other utilities normally found in the kernel's scripts directory. For >> the kernel source in the staging dir, these scripts have been removed to >> avoid mixing archiectures when packaging kernel-dev (among other things). >> >> Rather than further complicate the kernel's install rule, or its packaging, >> we can jump into the sysroot and restore the scripts by building them, hence >> making them available to packages that need them. >> >> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> >> --- >> meta/classes/kernel.bbclass | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >> index 4acfb7e..d856e31 100644 >> --- a/meta/classes/kernel.bbclass >> +++ b/meta/classes/kernel.bbclass >> @@ -294,6 +294,14 @@ do_install[prefuncs] += "package_get_auto_pr" >> >> sysroot_stage_all_append() { >> sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} >> + >> + # Restore kernel scripts in the sysroot, since they had to be removed during >> + # packaging to avoid mismatched arch QA errors, but are required/useful when >> + # packages like out of tree kernel modules are built. Rather than playing QA >> + # games, it is easier to just do this work in the sysroot. >> + ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; > > This was cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}/scripts in my patch but I will test out this one too. > but this is ok since Thanks. I went with habit and did it right from the top level. I see modpost in my sysroot, but I definitely want to get your confirmation that it works for you as well. Bruce > > ifeq ($(KBUILD_EXTMOD),) > # Additional helpers built in scripts/ > # Carefully list dependencies so we do not try to build scripts twice > # in parallel > PHONY += scripts > scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \ > asm-generic > $(Q)$(MAKE) $(build)=$(@) > > >> + oe_runmake scripts >> + ) >> } >> >> kernel_do_configure() { >> -- >> 1.8.1.2 >> > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-04 0:02 ` [PATCH 1/1] kernel: restore " Bruce Ashfield 2013-10-04 0:58 ` Khem Raj @ 2013-10-04 7:46 ` Richard Purdie 2013-10-04 12:42 ` Bruce Ashfield 2013-10-07 5:02 ` Bruce Ashfield 1 sibling, 2 replies; 37+ messages in thread From: Richard Purdie @ 2013-10-04 7:46 UTC (permalink / raw) To: Bruce Ashfield; +Cc: openembedded-core On Thu, 2013-10-03 at 20:02 -0400, Bruce Ashfield wrote: > When building against the sysroot, out of tree modules can require modpost > and other utilities normally found in the kernel's scripts directory. For > the kernel source in the staging dir, these scripts have been removed to > avoid mixing archiectures when packaging kernel-dev (among other things). Its also to avoid mixing architectures when packaging the sstate for do_populate_sysroot. The sstate for that task is now native arch specific after this patch but its task hash is not. Even if we made it native specific, that means the kernel would rebuild entirely if you switch 32 bit to 64 bit native machine. We therefore cannot merge this patch as is. Instead do something like: SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst" kernelheaders_sstate_postinst () { if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] then ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; oe_runmake scripts ) fi } This will rerun the oe_runmake scripts each time the sstate package is installed. It slows down the use of sstate but should be correct whether the build machine is 32 or 64 bit. Cheers, Richard ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-04 7:46 ` Richard Purdie @ 2013-10-04 12:42 ` Bruce Ashfield 2013-10-04 20:23 ` Khem Raj 2013-10-07 5:02 ` Bruce Ashfield 1 sibling, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-10-04 12:42 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On 13-10-04 03:46 AM, Richard Purdie wrote: > On Thu, 2013-10-03 at 20:02 -0400, Bruce Ashfield wrote: >> When building against the sysroot, out of tree modules can require modpost >> and other utilities normally found in the kernel's scripts directory. For >> the kernel source in the staging dir, these scripts have been removed to >> avoid mixing archiectures when packaging kernel-dev (among other things). > > Its also to avoid mixing architectures when packaging the sstate for > do_populate_sysroot. The sstate for that task is now native arch > specific after this patch but its task hash is not. Even if we made it > native specific, that means the kernel would rebuild entirely if you > switch 32 bit to 64 bit native machine. We therefore cannot merge this > patch as is. Aha! I knew there was a lurking element I wouldn't know about. I nearly put "RFC" in the patch .. and clearly should have :) > > Instead do something like: > > > SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst" > > kernelheaders_sstate_postinst () { > if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] > then > ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; > oe_runmake scripts > ) > fi > } > > This will rerun the oe_runmake scripts each time the sstate package is > installed. It slows down the use of sstate but should be correct whether > the build machine is 32 or 64 bit. I'll try what you have above and re-spin the patch. Cheers, Bruce > > > Cheers, > > Richard > > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-04 12:42 ` Bruce Ashfield @ 2013-10-04 20:23 ` Khem Raj 0 siblings, 0 replies; 37+ messages in thread From: Khem Raj @ 2013-10-04 20:23 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer Bruce Besides the sstate problem RP mentioned your patch worked fine. On Fri, Oct 4, 2013 at 5:42 AM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > On 13-10-04 03:46 AM, Richard Purdie wrote: >> >> On Thu, 2013-10-03 at 20:02 -0400, Bruce Ashfield wrote: >>> >>> When building against the sysroot, out of tree modules can require >>> modpost >>> and other utilities normally found in the kernel's scripts directory. For >>> the kernel source in the staging dir, these scripts have been removed to >>> avoid mixing archiectures when packaging kernel-dev (among other things). >> >> >> Its also to avoid mixing architectures when packaging the sstate for >> do_populate_sysroot. The sstate for that task is now native arch >> specific after this patch but its task hash is not. Even if we made it >> native specific, that means the kernel would rebuild entirely if you >> switch 32 bit to 64 bit native machine. We therefore cannot merge this >> patch as is. > > > Aha! I knew there was a lurking element I wouldn't know about. I nearly > put "RFC" in the patch .. and clearly should have :) > > >> >> Instead do something like: >> >> >> SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst" >> >> kernelheaders_sstate_postinst () { >> if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o >> "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] >> then >> ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; >> oe_runmake scripts >> ) >> fi >> } >> >> This will rerun the oe_runmake scripts each time the sstate package is >> installed. It slows down the use of sstate but should be correct whether >> the build machine is 32 or 64 bit. > > > I'll try what you have above and re-spin the patch. > > Cheers, > > Bruce > >> >> >> Cheers, >> >> Richard >> >> > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-04 7:46 ` Richard Purdie 2013-10-04 12:42 ` Bruce Ashfield @ 2013-10-07 5:02 ` Bruce Ashfield 2013-10-07 9:58 ` Richard Purdie 1 sibling, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-10-07 5:02 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On 13-10-04 3:46 AM, Richard Purdie wrote: > On Thu, 2013-10-03 at 20:02 -0400, Bruce Ashfield wrote: >> When building against the sysroot, out of tree modules can require modpost >> and other utilities normally found in the kernel's scripts directory. For >> the kernel source in the staging dir, these scripts have been removed to >> avoid mixing archiectures when packaging kernel-dev (among other things). > > Its also to avoid mixing architectures when packaging the sstate for > do_populate_sysroot. The sstate for that task is now native arch > specific after this patch but its task hash is not. Even if we made it > native specific, that means the kernel would rebuild entirely if you > switch 32 bit to 64 bit native machine. We therefore cannot merge this > patch as is. > > Instead do something like: > > > SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst" > > kernelheaders_sstate_postinst () { > if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] > then > ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; > oe_runmake scripts > ) > fi > } > > This will rerun the oe_runmake scripts each time the sstate package is > installed. It slows down the use of sstate but should be correct whether > the build machine is 32 or 64 bit. I poked with this a bit over the weekend, and never did get the right results. I can make the scripts trigger, but since the sysroot population appears to already be done, but build scripts don't actually make it into the sysroot for use during module builds. I tried a few variants of the below, all trying to get the actual tmp/sysroots/<machine> to have the scripts, with no luck. Dumping the available variables didn't get me anything really promising either. I'll have another look in the morning, since I'm sure it is just me not understanding the ordering of things .. but any pointers would of course be appreciated. Cheers, Bruce STATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" kernelscripts_sstate_postinst () { if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} oe_runmake -C ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} scripts fi } > > > Cheers, > > Richard > > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-07 5:02 ` Bruce Ashfield @ 2013-10-07 9:58 ` Richard Purdie 2013-10-07 15:20 ` Bruce Ashfield 0 siblings, 1 reply; 37+ messages in thread From: Richard Purdie @ 2013-10-07 9:58 UTC (permalink / raw) To: Bruce Ashfield; +Cc: openembedded-core On Mon, 2013-10-07 at 01:02 -0400, Bruce Ashfield wrote: > On 13-10-04 3:46 AM, Richard Purdie wrote: > > On Thu, 2013-10-03 at 20:02 -0400, Bruce Ashfield wrote: > >> When building against the sysroot, out of tree modules can require modpost > >> and other utilities normally found in the kernel's scripts directory. For > >> the kernel source in the staging dir, these scripts have been removed to > >> avoid mixing archiectures when packaging kernel-dev (among other things). > > > > Its also to avoid mixing architectures when packaging the sstate for > > do_populate_sysroot. The sstate for that task is now native arch > > specific after this patch but its task hash is not. Even if we made it > > native specific, that means the kernel would rebuild entirely if you > > switch 32 bit to 64 bit native machine. We therefore cannot merge this > > patch as is. > > > > Instead do something like: > > > > > > SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst" > > > > kernelheaders_sstate_postinst () { > > if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] > > then > > ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; > > oe_runmake scripts > > ) > > fi > > } > > > > This will rerun the oe_runmake scripts each time the sstate package is > > installed. It slows down the use of sstate but should be correct whether > > the build machine is 32 or 64 bit. > > I poked with this a bit over the weekend, and never did get the right > results. > > I can make the scripts trigger, but since the sysroot population appears > to already be done, but build scripts don't actually make it into the > sysroot for use during module builds. > > I tried a few variants of the below, all trying to get the actual > tmp/sysroots/<machine> to have the scripts, with no luck. Dumping the > available variables didn't get me anything really promising either. > > I'll have another look in the morning, since I'm sure it is just me not > understanding the ordering of things .. but any pointers would of course > be appreciated. > > Cheers, > > Bruce > > STATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" > kernelscripts_sstate_postinst () { > if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o > "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then > sysroot_stage_dir ${D}${KERNEL_SRC_PATH} > ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} > oe_runmake -C ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} scripts > fi > } > Ah, I had it slightly wrong. Try: kernelheaders_sstate_postinst () { if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] then ( cd ${KERNEL_SRC_PATH}; oe_runmake scripts ) fi } since the files are actually installed at this point, therefore we operate on the final location. The risk here is that when we uninstall the sstate package, we don't track the generated files. We can probably live with that for now. What we really needs is a preinst but the one we have is really a preunpack :/. Ultimately, I think we need to rename the preinst to preunpack and add a real preinst... Cheers, Richard ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-07 9:58 ` Richard Purdie @ 2013-10-07 15:20 ` Bruce Ashfield 2013-10-07 16:18 ` Richard Purdie 0 siblings, 1 reply; 37+ messages in thread From: Bruce Ashfield @ 2013-10-07 15:20 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On 13-10-07 05:58 AM, Richard Purdie wrote: > On Mon, 2013-10-07 at 01:02 -0400, Bruce Ashfield wrote: >> On 13-10-04 3:46 AM, Richard Purdie wrote: >>> On Thu, 2013-10-03 at 20:02 -0400, Bruce Ashfield wrote: >>>> When building against the sysroot, out of tree modules can require modpost >>>> and other utilities normally found in the kernel's scripts directory. For >>>> the kernel source in the staging dir, these scripts have been removed to >>>> avoid mixing archiectures when packaging kernel-dev (among other things). >>> >>> Its also to avoid mixing architectures when packaging the sstate for >>> do_populate_sysroot. The sstate for that task is now native arch >>> specific after this patch but its task hash is not. Even if we made it >>> native specific, that means the kernel would rebuild entirely if you >>> switch 32 bit to 64 bit native machine. We therefore cannot merge this >>> patch as is. >>> >>> Instead do something like: >>> >>> >>> SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst" >>> >>> kernelheaders_sstate_postinst () { >>> if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] >>> then >>> ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}; >>> oe_runmake scripts >>> ) >>> fi >>> } >>> >>> This will rerun the oe_runmake scripts each time the sstate package is >>> installed. It slows down the use of sstate but should be correct whether >>> the build machine is 32 or 64 bit. >> >> I poked with this a bit over the weekend, and never did get the right >> results. >> >> I can make the scripts trigger, but since the sysroot population appears >> to already be done, but build scripts don't actually make it into the >> sysroot for use during module builds. >> >> I tried a few variants of the below, all trying to get the actual >> tmp/sysroots/<machine> to have the scripts, with no luck. Dumping the >> available variables didn't get me anything really promising either. >> >> I'll have another look in the morning, since I'm sure it is just me not >> understanding the ordering of things .. but any pointers would of course >> be appreciated. >> >> Cheers, >> >> Bruce >> >> STATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst" >> kernelscripts_sstate_postinst () { >> if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o >> "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then >> sysroot_stage_dir ${D}${KERNEL_SRC_PATH} >> ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} >> oe_runmake -C ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} scripts >> fi >> } >> > > Ah, I had it slightly wrong. Try: > > kernelheaders_sstate_postinst () { > if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] > then > ( cd ${KERNEL_SRC_PATH}; > oe_runmake scripts > ) > fi > } > > since the files are actually installed at this point, therefore we > operate on the final location. That's the kicker, I can't get the right variable to find the final location, KERNEL_SRC_PATH is set to /usr/src/kernel, so we can't operate on it directly. When things were runing in the sysroot_append, the kernel src was staged, and then operated on, then it makes it into the sysroot. Here, we could operate on the STAGING_KERNEL, which is in the sysroot, but stripped of the scripts. Perhaps that is the answer, but I need to confirm that scripts installed in that location would be available to the out of tree module builds that are looking for modpost and friends. > > The risk here is that when we uninstall the sstate package, we don't > track the generated files. We can probably live with that for now. Agreed. > > What we really needs is a preinst but the one we have is really a > preunpack :/. > > Ultimately, I think we need to rename the preinst to preunpack and add a > real preinst... I'll keep digging. Cheers, Bruce > > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-07 15:20 ` Bruce Ashfield @ 2013-10-07 16:18 ` Richard Purdie 2013-10-07 16:20 ` Bruce Ashfield 0 siblings, 1 reply; 37+ messages in thread From: Richard Purdie @ 2013-10-07 16:18 UTC (permalink / raw) To: Bruce Ashfield; +Cc: openembedded-core On Mon, 2013-10-07 at 11:20 -0400, Bruce Ashfield wrote: > I had it slightly wrong. Try: > > > > kernelheaders_sstate_postinst () { > > if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] > > then > > ( cd ${KERNEL_SRC_PATH}; > > oe_runmake scripts > > ) > > fi > > } > > > > since the files are actually installed at this point, therefore we > > operate on the final location. > > That's the kicker, I can't get the right variable to find the final > location, KERNEL_SRC_PATH is set to /usr/src/kernel, so we can't operate > on it directly. When things were runing in the sysroot_append, the > kernel src was staged, and then operated on, then it makes it into the > sysroot. Here, we could operate on the STAGING_KERNEL, which is in the > sysroot, but stripped of the scripts. Perhaps that is the answer, but > I need to confirm that scripts installed in that location would be > available to the out of tree module builds that are looking for modpost > and friends. Guessing again (third time lucky?), cd ${STAGING_DIR_KERNEL}; ? Cheers, Richard ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/1] kernel: restore scripts in the sysroot 2013-10-07 16:18 ` Richard Purdie @ 2013-10-07 16:20 ` Bruce Ashfield 0 siblings, 0 replies; 37+ messages in thread From: Bruce Ashfield @ 2013-10-07 16:20 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On 13-10-07 12:18 PM, Richard Purdie wrote: > On Mon, 2013-10-07 at 11:20 -0400, Bruce Ashfield wrote: >> I had it slightly wrong. Try: >>> >>> kernelheaders_sstate_postinst () { >>> if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] >>> then >>> ( cd ${KERNEL_SRC_PATH}; >>> oe_runmake scripts >>> ) >>> fi >>> } >>> >>> since the files are actually installed at this point, therefore we >>> operate on the final location. >> >> That's the kicker, I can't get the right variable to find the final >> location, KERNEL_SRC_PATH is set to /usr/src/kernel, so we can't operate >> on it directly. When things were runing in the sysroot_append, the >> kernel src was staged, and then operated on, then it makes it into the >> sysroot. Here, we could operate on the STAGING_KERNEL, which is in the >> sysroot, but stripped of the scripts. Perhaps that is the answer, but >> I need to confirm that scripts installed in that location would be >> available to the out of tree module builds that are looking for modpost >> and friends. > > Guessing again (third time lucky?), > > cd ${STAGING_DIR_KERNEL}; Yah, that's where it lives. I'm building now and trying to validate Khem's use case. Bruce > > ? > > Cheers, > > Richard > > ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2013-11-20 4:43 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-10-08 21:12 [PATCH 0/1] kernel: restore scripts in the sysroot Bruce Ashfield 2013-10-08 21:12 ` [PATCH 1/1] " Bruce Ashfield 2013-11-19 17:37 ` Mike Crowe 2013-11-19 17:37 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Mike Crowe 2013-11-19 17:37 ` [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst Mike Crowe 2013-11-19 17:41 ` Bruce Ashfield 2013-11-19 17:46 ` Richard Purdie 2013-11-19 17:56 ` Bruce Ashfield 2013-11-19 17:49 ` Mike Crowe 2013-11-19 17:59 ` Phil Blundell 2013-11-19 17:47 ` [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene Bruce Ashfield 2013-11-19 17:46 ` [PATCH 1/1] kernel: restore scripts in the sysroot Phil Blundell 2013-11-19 17:54 ` Bruce Ashfield 2013-11-19 18:17 ` Bruce Ashfield 2013-11-19 22:29 ` Khem Raj 2013-11-19 22:36 ` Richard Purdie 2013-11-19 22:39 ` Khem Raj 2013-11-19 22:45 ` Richard Purdie 2013-11-20 2:59 ` Khem Raj 2013-11-20 4:43 ` Bruce Ashfield 2013-11-19 22:37 ` Bruce Ashfield 2013-11-19 22:42 ` Richard Purdie 2013-11-19 22:46 ` Bruce Ashfield 2013-11-19 23:44 ` Phil Blundell 2013-11-19 22:48 ` Bruce Ashfield 2013-11-19 23:41 ` Phil Blundell -- strict thread matches above, loose matches on Subject: below -- 2013-10-04 0:02 [PATCH 0/1] kernel: provide " Bruce Ashfield 2013-10-04 0:02 ` [PATCH 1/1] kernel: restore " Bruce Ashfield 2013-10-04 0:58 ` Khem Raj 2013-10-04 0:59 ` Bruce Ashfield 2013-10-04 7:46 ` Richard Purdie 2013-10-04 12:42 ` Bruce Ashfield 2013-10-04 20:23 ` Khem Raj 2013-10-07 5:02 ` Bruce Ashfield 2013-10-07 9:58 ` Richard Purdie 2013-10-07 15:20 ` Bruce Ashfield 2013-10-07 16:18 ` Richard Purdie 2013-10-07 16:20 ` Bruce Ashfield
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.