| Submitter | Paul Eggleton |
|---|---|
| Date | Aug. 17, 2011, 6:37 p.m. |
| Message ID | <8c4bf939c0906cd744debeb85d5d55de622c184e.1313606178.git.paul.eggleton@linux.intel.com> |
| Download | mbox | patch |
| Permalink | /patch/10131/ |
| State | New, archived |
| Headers | show |
Comments
On Wed, 2011-08-17 at 19:37 +0100, Paul Eggleton wrote: > +Files in the deploy directory will not be re-created automatically if you > +delete them. If you do delete a file, you will need to run: > + > + bitbake -c clean TARGET > + bitbake TARGET > + > +where TARGET is the name of the appropriate package or target e.g. > +"virtual/kernel" for the kernel, an image, etc. Doesn't it suffice to run "bitbake -f -c deploy TARGET"? p.
On Wednesday 17 August 2011 19:41:37 Phil Blundell wrote: > On Wed, 2011-08-17 at 19:37 +0100, Paul Eggleton wrote: > > +Files in the deploy directory will not be re-created automatically if > > you +delete them. If you do delete a file, you will need to run: > > + > > + bitbake -c clean TARGET > > + bitbake TARGET > > + > > +where TARGET is the name of the appropriate package or target e.g. > > +"virtual/kernel" for the kernel, an image, etc. > > Doesn't it suffice to run "bitbake -f -c deploy TARGET"? I guess it would, but I'm not sure we really want to be encouraging users to use -f. Cheers, Paul
Op 17 aug. 2011, om 20:37 heeft Paul Eggleton het volgende geschreven: > New users sometimes delete files in tmp/deploy/images assuming they will > be re-created just by re-running the build, and then are confused when > this doesn't work. To discourage people from doing this, create a file > called README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt in > tmp/deploy/images containing an explanation of what needs to be done to > re-create files there. > > Fixes [YOCTO #1315] and [YOCTO #1346]. > > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> > --- > meta/classes/image.bbclass | 2 ++ > meta/classes/kernel.bbclass | 2 ++ > meta/files/deploydir_readme.txt | 8 ++++++++ > 3 files changed, 12 insertions(+), 0 deletions(-) > create mode 100644 meta/files/deploydir_readme.txt > > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass > index 54eb78b..286ae01 100644 > --- a/meta/classes/image.bbclass > +++ b/meta/classes/image.bbclass > @@ -138,6 +138,8 @@ fakeroot do_rootfs () { > mkdir -p ${IMAGE_ROOTFS} > mkdir -p ${DEPLOY_DIR_IMAGE} > > + cp -n ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOY_DIR_IMAGE}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt > + That doesn't work on my debian box: | + cp -n /OE/tentacle/sources/openembedded-core/meta/files/deploydir_readme.txt /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy/images/beagleboard/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt | cp: invalid option -- 'n' | Try `cp --help' for more information.
* Koen Kooi <koen@dominion.thruhere.net> [110822 23:01]: > Op 17 aug. 2011, om 20:37 heeft Paul Eggleton het volgende geschreven: > > + cp -n ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOY_DIR_IMAGE}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt > > + > That doesn't work on my debian box: > | + cp -n /OE/tentacle/sources/openembedded-core/meta/files/deploydir_readme.txt /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy/images/beagleboard/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt > | cp: invalid option -- 'n' > | Try `cp --help' for more information. Which debian version are you running? I've seen no problem, as far as I can tell, on neither my ubuntu, nor my debian box. (Although I'm running debian sid on that one). Cheers, Anders
Op 23 aug. 2011, om 08:44 heeft Anders Darander het volgende geschreven: > * Koen Kooi <koen@dominion.thruhere.net> [110822 23:01]: >> Op 17 aug. 2011, om 20:37 heeft Paul Eggleton het volgende geschreven: >>> + cp -n ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOY_DIR_IMAGE}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt >>> + > >> That doesn't work on my debian box: > >> | + cp -n /OE/tentacle/sources/openembedded-core/meta/files/deploydir_readme.txt /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy/images/beagleboard/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt >> | cp: invalid option -- 'n' >> | Try `cp --help' for more information. > > Which debian version are you running? > > I've seen no problem, as far as I can tell, on neither my ubuntu, nor my > debian box. (Although I'm running debian sid on that one). koen@dominion:/OE/tentacle/sources/openembedded-core$ lsb_release -a /usr/bin/lsb_release:81: DeprecationWarning: the sets module is deprecated import sets No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 5.0 (lenny) Release: 5.0 Codename: lenny
On Tue, 2011-08-23 at 08:44 +0200, Anders Darander wrote: > * Koen Kooi <koen@dominion.thruhere.net> [110822 23:01]: > > Op 17 aug. 2011, om 20:37 heeft Paul Eggleton het volgende geschreven: > > > + cp -n ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOY_DIR_IMAGE}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt > > > + > > > That doesn't work on my debian box: > > > | + cp -n /OE/tentacle/sources/openembedded-core/meta/files/deploydir_readme.txt /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy/images/beagleboard/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt > > | cp: invalid option -- 'n' > > | Try `cp --help' for more information. > > Which debian version are you running? > > I've seen no problem, as far as I can tell, on neither my ubuntu, nor my > debian box. (Although I'm running debian sid on that one). Irrespective of whether it happens to work or not on some or other distro, "cp -n" isn't POSIX and we shouldn't be relying on it. I can't really see why the -n option is needed here anyway. It looks to me like it could just be removed with no ill effects. p.
On Tuesday 23 August 2011 10:22:12 Phil Blundell wrote: > Irrespective of whether it happens to work or not on some or other > distro, "cp -n" isn't POSIX and we shouldn't be relying on it. > > I can't really see why the -n option is needed here anyway. It looks to > me like it could just be removed with no ill effects. Sorry, I wasn't aware that it was a non-standard option. I'll post a new version with it removed. Cheers, Paul
On Tue, 2011-08-23 at 10:32 +0100, Paul Eggleton wrote: > On Tuesday 23 August 2011 10:22:12 Phil Blundell wrote: > > Irrespective of whether it happens to work or not on some or other > > distro, "cp -n" isn't POSIX and we shouldn't be relying on it. > > > > I can't really see why the -n option is needed here anyway. It looks to > > me like it could just be removed with no ill effects. > > Sorry, I wasn't aware that it was a non-standard option. I'll post a new > version with it removed. Yeah, POSIX cp only understands quite a restricted set of options. It supports -f, -i, -p, -R, plus -H, -L and -P in newer versions (and the obsolescent -r). Anything beyond that is not guaranteed. p.
On 08/19/2011 03:27 AM, Paul Eggleton wrote: > On Wednesday 17 August 2011 19:41:37 Phil Blundell wrote: >> On Wed, 2011-08-17 at 19:37 +0100, Paul Eggleton wrote: >>> +Files in the deploy directory will not be re-created automatically if >>> you +delete them. If you do delete a file, you will need to run: >>> + >>> + bitbake -c clean TARGET >>> + bitbake TARGET >>> + >>> +where TARGET is the name of the appropriate package or target e.g. >>> +"virtual/kernel" for the kernel, an image, etc. >> >> Doesn't it suffice to run "bitbake -f -c deploy TARGET"? > > I guess it would, but I'm not sure we really want to be encouraging users to > use -f. I don't see it as having the same negative conotation as the force options to things like rpm and dpkg. Here it just means "I really want to run this specific task again, even if you already ran it, likely because I know I did something to undo what you just did." :-) > > Cheers, > Paul >
On Tuesday 23 August 2011 20:08:08 you wrote: > On 08/19/2011 03:27 AM, Paul Eggleton wrote: > > I guess it would, but I'm not sure we really want to be encouraging users > > to use -f. > > I don't see it as having the same negative conotation as the force > options to things like rpm and dpkg. Here it just means "I really want > to run this specific task again, even if you already ran it, likely > because I know I did something to undo what you just did." :-) My concern is that not all tasks are repeatable; people could run into all sorts of trouble using this option under the wrong circumstances and it might be difficult to debug after the fact. Cheers, Paul
Op 23 aug. 2011 om 22:07 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven: > On Tuesday 23 August 2011 20:08:08 you wrote: >> On 08/19/2011 03:27 AM, Paul Eggleton wrote: >>> I guess it would, but I'm not sure we really want to be encouraging users >>> to use -f. >> >> I don't see it as having the same negative conotation as the force >> options to things like rpm and dpkg. Here it just means "I really want >> to run this specific task again, even if you already ran it, likely >> because I know I did something to undo what you just did." :-) > > My concern is that not all tasks are repeatable; I consider that a bug :) > could run into all > sorts of trouble using this option under the wrong circumstances and it might > be difficult to debug after the fact. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tuesday 23 August 2011 22:39:41 Koen Kooi wrote: > > My concern is that not all tasks are repeatable; > > I consider that a bug :) Why? If you use the system as intended it's never a problem. Cheers, Paul
Patch
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index 54eb78b..286ae01 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -138,6 +138,8 @@ fakeroot do_rootfs () { mkdir -p ${IMAGE_ROOTFS} mkdir -p ${DEPLOY_DIR_IMAGE} + cp -n ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOY_DIR_IMAGE}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt + if [ "${USE_DEVFS}" != "1" ]; then for devtable in ${@get_devtable_list(d)}; do makedevs -r ${IMAGE_ROOTFS} -D $devtable diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 386b05e..a2b10f2 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -500,6 +500,8 @@ kernel_do_deploy() { cd ${DEPLOYDIR} rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin + + cp -n ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt } do_deploy[dirs] = "${DEPLOYDIR} ${B}" diff --git a/meta/files/deploydir_readme.txt b/meta/files/deploydir_readme.txt new file mode 100644 index 0000000..97ec185 --- /dev/null +++ b/meta/files/deploydir_readme.txt @@ -0,0 +1,8 @@ +Files in the deploy directory will not be re-created automatically if you +delete them. If you do delete a file, you will need to run: + + bitbake -c clean TARGET + bitbake TARGET + +where TARGET is the name of the appropriate package or target e.g. +"virtual/kernel" for the kernel, an image, etc.
New users sometimes delete files in tmp/deploy/images assuming they will be re-created just by re-running the build, and then are confused when this doesn't work. To discourage people from doing this, create a file called README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt in tmp/deploy/images containing an explanation of what needs to be done to re-create files there. Fixes [YOCTO #1315] and [YOCTO #1346]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> --- meta/classes/image.bbclass | 2 ++ meta/classes/kernel.bbclass | 2 ++ meta/files/deploydir_readme.txt | 8 ++++++++ 3 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 meta/files/deploydir_readme.txt