kernel.bbclass: Add cleandirs for do_shared_workdir
PATCH 1/1 kernel.bbclass: Add cleandirs for do_shared_workdir
Ensure we have a clean and empty STAGING_KERNEL_BUILDDIR (kernel-build-artifacts) before creating it, otherwise there might be older artifacts from a prior kernel build.
[YOCTO #11880]
--- meta/classes/kernel.bbclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
meta/classes/kernel.bbclass +1 -2
@@ -400,6 +400,7 @@ emit_depmod_pkgdata() { PACKAGEFUNCS += "emit_depmod_pkgdata" +do_shared_workdir[cleandirs] += " ${STAGING_KERNEL_BUILDDIR}" do_shared_workdir () { cd ${B}
@@ -655,8 +656,6 @@ kernel_do_deploy() { fi done } -do_deploy[cleandirs] = "${DEPLOYDIR}" -do_deploy[dirs] = "${DEPLOYDIR} ${B}" do_deploy[prefuncs] += "package_get_auto_pr" addtask deploy after do_populate_sysroot do_packagedata
Signature · 1 line
2.13.5
Quoted 4 lines · Saul Wold
Ensure we have a clean and empty
STAGING_KERNEL_BUILDDIR(kernel-build-artifacts) before creating it, otherwise there might be older artifacts from a prior kernel build.
What's the actual error that this triggers ? It would be nice to log it here in the commit message .. or at least a description of the symptoms.
Quoted 20 lines
[YOCTO #11880]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/kernel.bbclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)meta/classes/kernel.bbclass +1
-0@@ -400,6 +400,7 @@ emit_depmod_pkgdata() { PACKAGEFUNCS += "emit_depmod_pkgdata" +do_shared_workdir[cleandirs] += " ${STAGING_KERNEL_BUILDDIR}" do_shared_workdir () { cd ${B}
meta/classes/kernel.bbclass kernel_do_deploy() { · line 659
Quoted 5 lines
meta/classes/kernel.bbclass +0
-2@@ -655,8 +656,6 @@ kernel_do_deploy() { fi done } -do_deploy[cleandirs] = "${DEPLOYDIR}" -do_deploy[dirs] = "${DEPLOYDIR} ${B}"
This isn't clear to me. Why does cleaning the STAGING_KERNEL_BUILDDIR as part of the do_shared_workdir mean that we no longer need the clean before the deploy (as well as the deploy dir).
Bruce
Quoted 4 lines
meta/classes/kernel.bbclass +0
-0do_deploy[prefuncs] += "package_get_auto_pr" addtask deploy after do_populate_sysroot do_packagedata
Quoted 8 lines · Bruce Ashfield
Quoted 6 lines · Saul Wold
Ensure we have a clean and empty
STAGING_KERNEL_BUILDDIR(kernel- build-artifacts)
before creating it, otherwise there might be older artifacts from a prior
kernel build.
Quoted 4 lines
What's the actual error that this triggers ? It would be nice to log it here in the commit message .. or at least a description of the symptoms.
As refered to in the bug, there is not an actual error occurs, but there are multiple older and non-appropriate (read older) artifacts remaining in the kernel-build-artifacts directory, just as the commit message describes.
Sau!
Quoted 39 lines
Quoted 21 lines
[YOCTO #11880]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/kernel.bbclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)meta/classes/kernel.bbclass +1
-0@@ -400,6 +400,7 @@ emit_depmod_pkgdata() { PACKAGEFUNCS += "emit_depmod_pkgdata" +do_shared_workdir[cleandirs] += " ${STAGING_KERNEL_BUILDDIR}" do_shared_workdir () { cd ${B}meta/classes/kernel.bbclass kernel_do_deploy() { · line 659
Quoted 5 lines
meta/classes/kernel.bbclass +0
-2@@ -655,8 +656,6 @@ kernel_do_deploy() { fi done } -do_deploy[cleandirs] = "${DEPLOYDIR}" -do_deploy[dirs] = "${DEPLOYDIR} ${B}"This isn't clear to me. Why does cleaning the
STAGING_KERNEL_BUILDDIRas part of thedo_shared_workdirmean that we no longer need the clean before the deploy (as well as the deploy dir).Bruce
Quoted 4 lines
meta/classes/kernel.bbclass +0
-0do_deploy[prefuncs] += "package_get_auto_pr" addtask deploy after do_populate_sysroot do_packagedata
Quoted 9 lines · Saul Wold
Quoted 8 lines · Bruce Ashfield
Quoted 6 lines · Saul Wold
Ensure we have a clean and empty
STAGING_KERNEL_BUILDDIR(kernel- build-artifacts)
before creating it, otherwise there might be older artifacts from a prior
kernel build.
Quoted 9 lines
Quoted 4 lines
What's the actual error that this triggers ? It would be nice to log it here in the commit message .. or at least a description of the symptoms.
As refered to in the bug, there is not an actual error occurs, but there are multiple older and non-appropriate (read older) artifacts remaining in the kernel-build-artifacts directory, just as the commit message describes.
Quoting a bug isn't useful .. everything that someone needs to know *must* be in a commit message. I'm not clicking through later on when doing a 'git whatchanged', and I may not even be online at that time .. so that bug reference just isn't useful.
So the old artifacts remain .. is it a disk usage question ? Is it a possible
confusion when inspecting a build ? .. All that the message does is describe the change, not the why.
Bruce
Quoted 48 lines
Sau!
Quoted 31 lines
Quoted 21 lines
[YOCTO #11880]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/kernel.bbclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)meta/classes/kernel.bbclass +1
-0@@ -400,6 +400,7 @@ emit_depmod_pkgdata() { PACKAGEFUNCS += "emit_depmod_pkgdata" +do_shared_workdir[cleandirs] += " ${STAGING_KERNEL_BUILDDIR}" do_shared_workdir () { cd ${B}meta/classes/kernel.bbclass kernel_do_deploy() { · line 659
Quoted 5 lines
meta/classes/kernel.bbclass +0
-2@@ -655,8 +656,6 @@ kernel_do_deploy() { fi done } -do_deploy[cleandirs] = "${DEPLOYDIR}" -do_deploy[dirs] = "${DEPLOYDIR} ${B}"This isn't clear to me. Why does cleaning the
STAGING_KERNEL_BUILDDIRas part of thedo_shared_workdirmean that we no longer need the clean before the deploy (as well as the deploy dir).Quoted 8 lines
Bruce
Quoted 4 lines
meta/classes/kernel.bbclass +0
-0do_deploy[prefuncs] += "package_get_auto_pr" addtask deploy after do_populate_sysroot do_packagedata--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 28 lines · Bruce Ashfield
Quoted 9 lines · Saul Wold
Quoted 8 lines · Bruce Ashfield
Quoted 6 lines · Saul Wold
Ensure we have a clean and empty
STAGING_KERNEL_BUILDDIR(kernel- build-artifacts)
before creating it, otherwise there might be older artifacts from a prior
kernel build.Quoted 9 lines
Quoted 4 lines
What's the actual error that this triggers ? It would be nice to log it here in the commit message .. or at least a description of the symptoms.
As refered to in the bug, there is not an actual error occurs, but there are multiple older and non-appropriate (read older) artifacts remaining in the kernel-build-artifacts directory, just as the commit message describes.
Quoting a bug isn't useful .. everything that someone needs to know *must* be in a commit message. I'm not clicking through later on when doing a 'git whatchanged', and I may not even be online at that time .. so that bug reference just isn't useful.
Quoted 6 lines
So the old artifacts remain .. is it a disk usage question ? Is it a possible
confusion when inspecting a build ? .. All that the message does is describe the change, not the why.
I should have highlighted my real question, change log semantics and nitpicking are just noise :D See below in the double quoted reply.
Quoted 40 lines
Bruce
Quoted 35 lines
Sau!
Quoted 31 lines
Quoted 21 lines
[YOCTO #11880]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/kernel.bbclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)meta/classes/kernel.bbclass +1
-0@@ -400,6 +400,7 @@ emit_depmod_pkgdata() { PACKAGEFUNCS += "emit_depmod_pkgdata" +do_shared_workdir[cleandirs] += " ${STAGING_KERNEL_BUILDDIR}" do_shared_workdir () { cd ${B}meta/classes/kernel.bbclass kernel_do_deploy() { · line 659
Quoted 5 lines
meta/classes/kernel.bbclass +0
-2@@ -655,8 +656,6 @@ kernel_do_deploy() { fi done } -do_deploy[cleandirs] = "${DEPLOYDIR}" -do_deploy[dirs] = "${DEPLOYDIR} ${B}"This isn't clear to me. Why does cleaning the
STAGING_KERNEL_BUILDDIRas part of thedo_shared_workdirmean that we no longer need the clean before the deploy (as well as the deploy dir).
It was this that was the real part of the question. The removal of these cleandirs
didn't seem to be directly replaced by the new method. Is it that the DEPLOYDIR
and STAGING_KERNEL_BUILDDIR are the same thing ?
Bruce
Quoted 21 lines
Quoted 8 lines
Bruce
Quoted 7 lines
meta/classes/kernel.bbclass kernel_do_deploy() { · line 661
Quoted 5 lines
meta/classes/kernel.bbclass +0
-0do_deploy[prefuncs] += "package_get_auto_pr" addtask deploy after do_populate_sysroot do_packagedataQuoted 6 lines
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 44 lines · Bruce Ashfield
Quoted 33 lines · Bruce Ashfield
Quoted 16 lines · Saul Wold
Quoted 2 lines · Bruce Ashfield
Quoted 1 line · Saul Wold
Ensure we have a clean and empty
STAGING_KERNEL_BUILDDIR(kernel-
Quoted 2 lines
Quoted 2 lines
build-artifacts)
before creating it, otherwise there might be older artifactsfrom a
Quoted 5 lines
Quoted 3 lines
prior
kernel build.What's the actual error that this triggers ? It would be nice
to
Quoted 3 lines
log it here in the commit message .. or at least a description of the symptoms.
Quoted 7 lines
As refered to in the bug, there is not an actual error occurs, but
there are multiple older and non-appropriate (read older) artifacts
remaining in the kernel-build-artifacts directory, just as the commit
message describes.Quoting a bug isn't useful .. everything that someone needs to know
*must* be in a commit message. I'm not clicking through later on when doing a 'git whatchanged', and I may not even be online at that time .. so that bug reference just isn't useful.Quoted 6 lines
So the old artifacts remain .. is it a disk usage question ? Is it a possible
confusion when inspecting a build ? .. All that the message does is describe the change, not the why.
Quoted 3 lines
I should have highlighted my real question, change log semantics and nitpicking are just noise :D See below in the double quoted reply.
Sorry, I missed the real question!
Quoted 41 lines
Quoted 39 lines
Bruce
Quoted 36 lines
Sau!
Quoted 14 lines
Quoted 14 lines
[YOCTO #11880]
Signed-off-by Saul Wold <[email protected]>--- meta/classes/kernel.bbclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)meta/classes/kernel.bbclass +0
-0@@ -400,6 +400,7 @@ emit_depmod_pkgdata() {Quoted 3 lines
meta/classes/kernel.bbclass emit_depmod_pkgdata() {
Quoted 3 lines
meta/classes/kernel.bbclass +1
-0PACKAGEFUNCS += "emit_depmod_pkgdata" +do_shared_workdir[cleandirs] += "${STAGING_KERNEL_BUILDDIR}"
Quoted 11 lines
meta/classes/kernel.bbclass kernel_do_deploy() { · line 659
Quoted 9 lines
meta/classes/kernel.bbclass +0
-2do_shared_workdir () { cd ${B}@@ -655,8 +656,6 @@ kernel_do_deploy() { fi done } -do_deploy[cleandirs] = "${DEPLOYDIR}" -do_deploy[dirs] = "${DEPLOYDIR} ${B}"This isn't clear to me. Why does cleaning the
STAGING_KERNEL_BUILDDIRQuoted 1 line
as part of the
do_shared_workdirmean that we no longer needthe
Quoted 2 lines
clean before the deploy (as well as the deploy dir).
Quoted 6 lines
It was this that was the real part of the question. The removal of these cleandirs
didn't seem to be directly replaced by the new method. Is it that the DEPLOYDIR
andSTAGING_KERNEL_BUILDDIRare the same thing ?
Yeah, oops, those where not meant to be removed, not sure what happened or why I missed it on review.
Sau!
Quoted 24 lines
Bruce
Quoted 19 lines
Quoted 13 lines
Quoted 8 lines
Bruce
Quoted 4 lines
meta/classes/kernel.bbclass +0
-0do_deploy[prefuncs] += "package_get_auto_pr" addtask deploy after do_populate_sysroot do_packagedata--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-coreSignature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"