yocto@lists.yoctoproject.org

Home Messages Hashtags Subgroups

Expanded

Between

and

Re: tentative list of vars to be dropped from variable glossary Richard Purdie #5566 On Mon, 2012-03-26 at 12:42 -0700, Rudolf Streif wrote: Another variable that seems to be dropped from the latest 1.1.1 revision of the Reference Manual is BBMASK. In previous versions of the manual it was explained that this variable can be used to remove packages from images. However, that did not work for me and it did not surprise me either. BBMASK removes recipes from being parsed. It does not remove them from images although that would I guess be an indirect result since you could no longer build them. To include a package with an image you will have to make it a dependency of that image. If you then hide the recipe of the package using BBMASK then you are breaking the dependency and the Bitbake will complain with "Nothing provides <package>" because the dependency is still there. I could not think of any other use case for BBMASK in the way it is implemented. Are there any? Its designed so that if you for example didn't care out any gpe recipe, you could exclude them entirely and not even have the parse overhead. Its less useful now things are split into layers but nonetheless still valid syntax. Cheers, Richard
More All Messages By This Member
Re: can all of the licensing discussion be centralized in an appendix? Rifenbark, Scott M <scott.m.rifenbark@...> #5565 Rudi, Great comments! Thanks very much. I will immediately update the revision history tables to show the 1.2 release as WIP. Not having it there did cause you confusion. Good suggestion. Regarding your other observations. If you have the time I would appreciate you looking at the YP Development manual, particularly Chapter 4. Much of the “how-to” stuff that was in the YP reference manual has been moved to there. “Adding a Package” section that you noted was now missing is in fact in that area. Let me give you some background on the strategy of the two manuals…. I am trying to eventually turn the YP reference guide into a “reference” guide with minimal “how-to” information. That is the long-term goal. The YP Development Manual has been getting some how-to stuff added to it. Chapter 4 (Common Tasks) tells how to create layers, add a package, customize images, etc.). Here is the link to the “latest” YP Development Manual: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html. With this new context, maybe you can augment or comment on your previous comments J I appreciate your help, Scott toggle quoted message Show quoted text From: rstreif@... [mailto:rstreif@...] On Behalf Of Rudolf Streif Sent: Monday, March 26, 2012 4:02 PM To: Rifenbark, Scott M Cc: yocto@... Subject: Re: [yocto] can all of the licensing discussion be centralized in an appendix? Scott, >> http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html. Yes, I looked at that one but I now noticed that I referenced it incorrectly. This is the latest version, however, in the revision history it shows "Revision 1.1, October 6, 2011, Released with the Yocto Project Release 1.1". Now, this one http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html is the current one but its revision history shows "Revision 1.1.1, March 15, 2012, Released with the Yocto Project Release 1.1.1". Ok, now I get how I confused myself successfully. I presume that the first is the newer one although its revision history suggests otherwise? Would you mind updating the revision history with something like "Revision 1.2, WIP, To be released with Yocto Project Release 1.2"? The latest one does not seem to have a section about writing recipes anymore at all. Are you planning on putting it back? While the previous one had a section on writing recipes it did so in a "vacuum". It told you how to write a recipe but not really where to put it and how to include it with an image. The latter it explained in the next section about customizing an image. The info about the licensing is great and dead-nuts on, however, a reader new to the Yocto Project would be missing the context. A good add-on to that paragraph would be that if you omit the md5 parameter in the LIC_FILES_CHKSUM variable Bitbake will actually spit it out for you which is in particular useful if the checksum is calculated over a subset of a license file specified by startline and endline because md5sum won't easily do that for you. These are my suggestions: * Remove 3.3 x32 and 3.4 Licenses from section 3. Section 3 currently looks a little bit like a kitchen sink. The first two paragraphs deal with build system components and architecture, x32 then mixes a very specific technology into it for particular targets, and then Licenses tops it off with package licensing details. I would dedicate Section 3 to Yocto Project Build System Architecture only. * Then I would dedicate a section 4 to Build Customization: The first subsection could deal with the most trivial customization through local.conf: EXTRA_IMAGE_FEATURES, IMAGE_INSTALL_append and CORE_IMAGE_EXTRA_INSTALL (formerly known as POKY_EXTRA_INSTALL) The second subsection should then explain how to create your own layer within the build environment because before adding any recipe you need to have a layer to add it to. Mixing your own recipes in with meta or meta-yocto works but is not sustainable when upgrading to a newer release of the Yocto Project. And it's good practice too to keep your own stuff separate. The third subsection should then explain how to extend images writing your own recipes: * writing a recipe that includes a base image and then adds more packages: require recipes-core/images/core-imabg-base.bb IMAGE_INSTALL += "strace" * writing an image that inherits from core-image IMAGE_INSTALL = "task-core-boot task-core-extended" IMAGE_FEATURES += "blabla" inherit core-image the fourth subsection should then explain how to add your own packages with your own recipes. Now you already have everything in place: a layer to add to and a ways of including your recipes with an image. And here we then also need to explain the licensing stuff because recipes for building packages won't fly without. the fifth section should then just reference the BSP manual for BSPs. Finally for my concept, we need to find a home for x32. I would put that under an "Advanced Topics" section which could act as a container for other stuff too such as multi-lib etc. Rudi From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Rudolf Streif Sent: Monday, March 26, 2012 2:52 PM To: yocto@... Subject:** Re: [yocto] can all of the licensing discussion be centralized in an appendix? >> there's way too much coverage of licensing sprinkled throughout. >> most people are not going to care about licensing until the time comes >> to maybe start distributing their BSP. The ability of collecting licensing information, tracking license changes and providing the license information automatically with the images and packages for deployment is in my opinion a major feature of Yocto albeit underestimated. Most people will only appreciate it once they have to deliver that information with a product for the end user. However, it starts much earlier, with the recipe. How to include licensing tracking information with your recipe needs to be part of the section explaining how to write recipes of the reference manual. In both, the current 1.1 and the upcoming 1.1.1, versions of the manual the license tracking section is a little disjoint from the sections explaining how to add packages/recipes in my opinion. The examples include the license tracking info, of course because otherwise the sanity checker will not allow building the recipe, but they don't explain that you actually need it (unless you use LICENSE = "CLOSED"). Since the license tracking and deployment feature follows the rule "garbage in, garbage out" the manual cannot stress enough providing the correct info in particular when writing recipes for upstream projects. Side note: And nice features for a future release are SPDX info (already worked on as far as I know) and providing the license info in ${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/images so that one knows what licenses are in use for what image. That would be very convenient when building multiple images with different package content. Rudi
More
Re: can all of the licensing discussion be centralized in an appendix? Rudolf Streif <rudolf.streif@...> #5564 Scott, >> http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html. Yes, I looked at that one but I now noticed that I referenced it incorrectly. This is the latest version, however, in the revision history it shows "Revision 1.1, October 6, 2011, Released with the Yocto Project Release 1.1". Now, this one http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html is the current one but its revision history shows "Revision 1.1.1, March 15, 2012, Released with the Yocto Project Release 1.1.1". Ok, now I get how I confused myself successfully. I presume that the first is the newer one although its revision history suggests otherwise? Would you mind updating the revision history with something like "Revision 1.2, WIP, To be released with Yocto Project Release 1.2"? The latest one does not seem to have a section about writing recipes anymore at all. Are you planning on putting it back? While the previous one had a section on writing recipes it did so in a "vacuum". It told you how to write a recipe but not really where to put it and how to include it with an image. The latter it explained in the next section about customizing an image. The info about the licensing is great and dead-nuts on, however, a reader new to the Yocto Project would be missing the context. A good add-on to that paragraph would be that if you omit the md5 parameter in the LIC_FILES_CHKSUM variable Bitbake will actually spit it out for you which is in particular useful if the checksum is calculated over a subset of a license file specified by startline and endline because md5sum won't easily do that for you. These are my suggestions: * Remove 3.3 x32 and 3.4 Licenses from section 3. Section 3 currently looks a little bit like a kitchen sink. The first two paragraphs deal with build system components and architecture, x32 then mixes a very specific technology into it for particular targets, and then Licenses tops it off with package licensing details. I would dedicate Section 3 to Yocto Project Build System Architecture only. * Then I would dedicate a section 4 to Build Customization: The first subsection could deal with the most trivial customization through local.conf: EXTRA_IMAGE_FEATURES, IMAGE_INSTALL_append and CORE_IMAGE_EXTRA_INSTALL (formerly known as POKY_EXTRA_INSTALL) The second subsection should then explain how to create your own layer within the build environment because before adding any recipe you need to have a layer to add it to. Mixing your own recipes in with meta or meta-yocto works but is not sustainable when upgrading to a newer release of the Yocto Project. And it's good practice too to keep your own stuff separate. The third subsection should then explain how to extend images writing your own recipes: * writing a recipe that includes a base image and then adds more packages: require recipes-core/images/core-imabg-base.bb IMAGE_INSTALL += "strace" * writing an image that inherits from core-image IMAGE_INSTALL = "task-core-boot task-core-extended" IMAGE_FEATURES += "blabla" inherit core-image the fourth subsection should then explain how to add your own packages with your own recipes. Now you already have everything in place: a layer to add to and a ways of including your recipes with an image. And here we then also need to explain the licensing stuff because recipes for building packages won't fly without. the fifth section should then just reference the BSP manual for BSPs. Finally for my concept, we need to find a home for x32. I would put that under an "Advanced Topics" section which could act as a container for other stuff too such as multi-lib etc. Rudi From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Rudolf Streif Sent: Monday, March 26, 2012 2:52 PM To: yocto@... Subject:** Re: [yocto] can all of the licensing discussion be centralized in an appendix? >> there's way too much coverage of licensing sprinkled throughout. >> most people are not going to care about licensing until the time comes >> to maybe start distributing their BSP. The ability of collecting licensing information, tracking license changes and providing the license information automatically with the images and packages for deployment is in my opinion a major feature of Yocto albeit underestimated. Most people will only appreciate it once they have to deliver that information with a product for the end user. However, it starts much earlier, with the recipe. How to include licensing tracking information with your recipe needs to be part of the section explaining how to write recipes of the reference manual. In both, the current 1.1 and the upcoming 1.1.1, versions of the manual the license tracking section is a little disjoint from the sections explaining how to add packages/recipes in my opinion. The examples include the license tracking info, of course because otherwise the sanity checker will not allow building the recipe, but they don't explain that you actually need it (unless you use LICENSE = "CLOSED"). Since the license tracking and deployment feature follows the rule "garbage in, garbage out" the manual cannot stress enough providing the correct info in particular when writing recipes for upstream projects. Side note: And nice features for a future release are SPDX info (already worked on as far as I know) and providing the license info in ${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/images so that one knows what licenses are in use for what image. That would be very convenient when building multiple images with different package content. Rudi
More
Re: pseudo interaction issue Richard Purdie #5548 On Mon, 2012-03-26 at 12:18 -0500, Peter Seebach wrote: On Mon, 26 Mar 2012 17:47:29 +0100 Richard Purdie <richard.purdie@...> wrote: This is pretty much what we do at the moment, it gets unset after we load. Pseudo is of course disabled at this point. I guess we just got lucky to this point and avoided "Bad Things"? I suspect so. What's weird to me is that PSEUDO_PREFIX wasn't in the environment before, either. So I still don't quite get this. I am still missing something which will make this all make sense. ... at this point, I am leaning towards viewing this as a bug where it is not enough to simply correct the behavior, I will not feel confident in it until I have understood how it could have happened, but worked in many other cases. This is why I'm not saying lets just set PSEUDO_PREFIX. Its bothering me too. What puzzles me is we get this value from envbackup[key] = os.environ.get("PSEUDO_PREFIX") so its already not in the environment. So basically if we read "PSEUDO_PREFIX" from the environment we get nothing. If we unset the value back to being "nothing", things break. Yes. This is, of course, obviously impossible. Obviously :). Except the code does this and I've watched it happen. I'm not claiming to understand it... Hmm. Well, hmm. When we start up, we should pick up PSEUDO_PREFIX from our environment, and during some of the initial client setup, we should be stashing that value in our stashed values table. At this point, so far as I can tell, nothing should ever unset that stashed value. On fork(), we don't change anything until we're in the client side of the fork, but that setup should happen in the same address space, with the values still stashed. When we poke new values into the environment, will it corrupt the internal stash? Oh, nevermind, I just realized: We use antimagic as the implementation goo for PSEUDO_DISABLED. So a call to os.popen() from a program which has PSEUDO_DISABLED set is going to think it's in antimagic mode. And suddenly, the trick is revealed: os.popen() is bypassing all the runqueue stuff which is trying to ensure that the environment is in a valid state. So if bitbake code calls os.popen(), it may behave weirdly, for the same reason that any other direct invocation of fork() or system() or whatnot would behave weirdly -- because bitbake is running with pseudo in a strange state. I'd be very surprised if we don't make some other system() call somewhere in bitbake's parent context. If this were a trigger, it could go a long way to explaining some errors people have reported though. So I think the thing is: Because bitbake is running with PSEUDO_DISABLED, any child process that is not explicitly set to either enable or unload pseudo is going to be running under pseudo, with PSEUDO_DISABLED. And that means we need to ensure that PSEUDO_PREFIX stays set, because we need that even when pseudo is disabled. (It's used during some of the initial setup sanity checks.) This is the answer I was expecting we'd come to. I'm still a little surprised we don't make any system() calls though. I just tried putting a os.system("true") call into the "breakit" class and it doesn't trigger the warnings. Could that be down to the lack of a popen wrapper? Cheers, Richard
More All Messages By This Member
[PATCH 2/2] sato: Remove questioned ISO image Yang Shi <yang.shi@...> #5546 [YOCTO #1487] For the liveCD image, interactive bootup is needed, but psplash prevents from booting interactively. In such case ISO image is not usable, so remove ISO image and the corresponding link and throw error info to warn outside to enable unionfs in kenrel. Signed-off-by: Yang Shi <yang.shi@...> --- meta/recipes-sato/images/core-image-sato.bb \| 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/meta/recipes-sato/images/core-image-sato.bb b/meta/recipes-sato/images/core-image-sato.bb index 11c3318..10e2239 100644 --- a/meta/recipes-sato/images/core-image-sato.bb +++ b/meta/recipes-sato/images/core-image-sato.bb @@ -9,3 +9,19 @@ IMAGE_FEATURES += "apps-console-core ${SATO_IMAGE_FEATURES}" LICENSE = "MIT" inherit core-image + +LIVE = "${@base_contains('IMAGE_FSTYPES', 'live', 'yes', 'no', d)}" + +do_check_unionfs() { + if [ "${NOISO}" = "1" ]; then + return + fi + + if [ "${LIVE}" = "yes" ] && ! grep -q "CONFIG_UNION_FS=y" ${STAGING_KERNEL_DIR}/.config; then + rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso + rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso + bbfatal "Building LIVE CD without UNION FS enabled in kernel" + fi +} + +addtask check_unionfs before do_build after do_bootimg -- 1.7.5.4
More
[PATCH 1/2] initrdscripts: fix init-live.sh and use unionfs Yang Shi <yang.shi@...> #5545 [YOCTO #1487] Use unionfs to mount rootfs and make root file system can be writen when using liveCD to boot up. Set UNION_FS variable depending on kenrel config, so that it can work with kernel which doesn't have unionfs feature. Signed-off-by: Yang Shi <yang.shi@...> --- meta/recipes-core/initrdscripts/files/init-live.sh \| 21 +++++++++++++++++-- .../initrdscripts/initramfs-live-boot_1.0.bb \| 9 +++++++- 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh b/meta/recipes-core/initrdscripts/files/init-live.sh index eb5ab5b..abaf16c 100644 --- a/meta/recipes-core/initrdscripts/files/init-live.sh +++ b/meta/recipes-core/initrdscripts/files/init-live.sh @@ -7,6 +7,7 @@ ROOT_IMAGE="rootfs.img" MOUNT="/bin/mount" UMOUNT="/bin/umount" ISOLINUX="" +UNIONFS="no" early_setup() { mkdir /proc @@ -89,10 +90,24 @@ case $label in mkdir $ROOT_MOUNT mknod /dev/loop0 b 7 0 2>/dev/null - if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then - fatal "Couldnt mount rootfs image" + + if [ "$UNIONFS" = "yes" ]; then + mkdir /rootfs-tmp + + if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE /rootfs-tmp ; then + fatal "Couldnt mount rootfs image" + else + mkdir /cow + mount -t tmpfs -o rw,noatime,mode=755 tmpfs /cow + mount -t unionfs -o dirs=/cow:/rootfs-tmp=ro unionfs $ROOT_MOUNT + boot_live_root + fi else - boot_live_root + if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then + fatal "Couldnt mount rootfs image" + else + boot_live_root + fi fi ;; install) diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb index e85a0e1..f7f0c9d 100644 --- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb +++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb @@ -2,10 +2,17 @@ DESCRIPTION = "A live image init script" LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420" RDEPENDS = "udev" +DEPENDS = "virtual/kernel" SRC_URI = "file://init-live.sh" -PR = "r7" +PR = "r8" +do_compile() { + if grep -q "CONFIG_UNION_FS=y" ${STAGING_KERNEL_DIR}/.config; then + sed -i 's/UNIONFS="no"/UNIONFS="yes"/g' ${WORKDIR}/init-live.sh + fi +} + do_install() { install -m 0755 ${WORKDIR}/init-live.sh ${D}/init } -- 1.7.5.4
More
[PATCH 0/2] Fix init-live.sh to use unionfs for live CD and remove questioned ISO image Yang Shi <yang.shi@...> #5547 Use unionfs to mount rootfs and make root file system can be writen when using liveCD to boot up. Set UNION_FS variable depending on kenrel config, so that it can work with kernel which doesn't have unionfs feature. Without UNION FS enabled in kernel, minimal liveCD image can be bootup to ignore the failure of mouting read-only filesystem. For the sato liveCD image, interactive bootup is needed, but psplash prevents from booting interactively. In such case ISO image is not usable, so remove ISO image and the corresponding link and throw error info to warn outside to enable unionfs in kenrel. We tried a lot of different ways to achieve this: 1. Check if ISO image is built in initramfs-live-boot.bb or not, then prevent from generating ISO image. But, we can't distinguish minimal image or sato image. 2. Check if x11 feature is included in initramfs-live-boot.bb or not, then prevent from generating ISO image. But, x11 feature is contained in minimal image as well even though the package is not built. 3. Tried to append some check code in build_iso() in core-image-sato.bb, but poky can't support append code in build_xxx functions like what we do for do_xxx funcitons. So, we came up with current solution. Any new suggestion is appreciated. One more thing is that if IMAGE_FSTYPE += "live" is not set in conf/local.conf with this fix, we will get below error when building sato image: ERROR: Running idle function Traceback (most recent call last): File "/home/yshi/yocto/poky/bitbake/lib/bb/server/process.py", line 122, in ProcessServer.idle_commands(delay=0.1): try: > retval = function(self, data, False) if retval is False: File "/home/yshi/yocto/poky/bitbake/lib/bb/cooker.py", line 1130, in buildTargetsIdle(server=<ProcessServer(ProcessServer-1, started)>, rq=<bb.runqueue.RunQueue instance at 0x74e4638>, abort=False): try: > retval = rq.execute_runqueue() except runqueue.TaskFailure as exc: File "/home/yshi/yocto/poky/bitbake/lib/bb/runqueue.py", line 947, in RunQueue.execute_runqueue(): self.rqexe = RunQueueExecuteDummy(self) > if self.rqdata.prepare() == 0: self.state = runQueueComplete File "/home/yshi/yocto/poky/bitbake/lib/bb/runqueue.py", line 719, in RunQueueData.prepare(): procdep.append(self.taskData.fn_index[self.runq_fnid[dep]] + "." + self.runq_task[dep]) > self.runq_hash[task] = bb.parse.siggen.get_taskhash(self.taskData.fn_index[self.runq_fnid[task]], self.runq_task[task], procdep, self.dataCache) File "/home/yshi/yocto/poky/bitbake/lib/bb/siggen.py", line 153, in SignatureGeneratorOEBasicHash.get_taskhash(fn='/home/yshi/yocto/poky/meta/recipes-sato/images/core-image-sato.bb', task='do_bootimg', deps=[], dataCache=<bb.cache.CacheData object at 0x2148490>): k = fn + "." + task > data = dataCache.basetaskhash[k] self.runtaskdeps[k] = [] KeyError: '/home/yshi/yocto/poky/meta/recipes-sato/images/core-image-sato.bb.do_bootimg' NOTE: Preparing runqueue Bruce pointed out there was a large discussion about this on hte list last week, so this should be a known issue in poky. The following changes since commit f81b0593e74a31cb2d992df0583948ff57e3ed98: gdbm: Activate -enable-libgdbm-compat and add symlinks to headers in include/gdbm (2012-03-23 17:56:29 +0200) are available in the git repository at: git://git.yoctoproject.org/poky-contrib yshi/1487 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=yshi/1487 Yang Shi (2): initrdscripts: fix init-live.sh and use unionfs sato: Remove questioned ISO image meta/recipes-core/initrdscripts/files/init-live.sh \| 21 +++++++++++++++++-- .../initrdscripts/initramfs-live-boot_1.0.bb \| 9 +++++++- meta/recipes-sato/images/core-image-sato.bb \| 16 +++++++++++++++ 3 files changed, 42 insertions(+), 4 deletions(-)
More
Re: can all of the licensing discussion be centralized in an appendix? Rifenbark, Scott M <scott.m.rifenbark@...> #5544 Rudi, I would like you to examine the “latest” documents (the ones under development). I have added some new licensing information and would like your feedback for this upcoming version. There are licensing discussions in both the latest versions of the BSP Guide and the reference manual. Since, at the moment, the BSP Guide is included as a chapter in the reference manual, I’ll point you to the latest version of the reference manual: http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html. Thanks, Scott toggle quoted message Show quoted text From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Rudolf Streif Sent: Monday, March 26, 2012 2:52 PM To: yocto@... Subject: Re: [yocto] can all of the licensing discussion be centralized in an appendix? >> there's way too much coverage of licensing sprinkled throughout. >> most people are not going to care about licensing until the time comes >> to maybe start distributing their BSP. The ability of collecting licensing information, tracking license changes and providing the license information automatically with the images and packages for deployment is in my opinion a major feature of Yocto albeit underestimated. Most people will only appreciate it once they have to deliver that information with a product for the end user. However, it starts much earlier, with the recipe. How to include licensing tracking information with your recipe needs to be part of the section explaining how to write recipes of the reference manual. In both, the current 1.1 and the upcoming 1.1.1, versions of the manual the license tracking section is a little disjoint from the sections explaining how to add packages/recipes in my opinion. The examples include the license tracking info, of course because otherwise the sanity checker will not allow building the recipe, but they don't explain that you actually need it (unless you use LICENSE = "CLOSED"). Since the license tracking and deployment feature follows the rule "garbage in, garbage out" the manual cannot stress enough providing the correct info in particular when writing recipes for upstream projects. Side note: And nice features for a future release are SPDX info (already worked on as far as I know) and providing the license info in ${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/images so that one knows what licenses are in use for what image. That would be very convenient when building multiple images with different package content. Rudi
More
Re: can all of the licensing discussion be centralized in an appendix? Rudolf Streif <rudolf.streif@...> #5543 >> there's way too much coverage of licensing sprinkled throughout. >> most people are not going to care about licensing until the time comes >> to maybe start distributing their BSP. The ability of collecting licensing information, tracking license changes and providing the license information automatically with the images and packages for deployment is in my opinion a major feature of Yocto albeit underestimated. Most people will only appreciate it once they have to deliver that information with a product for the end user. However, it starts much earlier, with the recipe. How to include licensing tracking information with your recipe needs to be part of the section explaining how to write recipes of the reference manual. In both, the current 1.1 and the upcoming 1.1.1, versions of the manual the license tracking section is a little disjoint from the sections explaining how to add packages/recipes in my opinion. The examples include the license tracking info, of course because otherwise the sanity checker will not allow building the recipe, but they don't explain that you actually need it (unless you use LICENSE = "CLOSED"). Since the license tracking and deployment feature follows the rule "garbage in, garbage out" the manual cannot stress enough providing the correct info in particular when writing recipes for upstream projects. Side note: And nice features for a future release are SPDX info (already worked on as far as I know) and providing the license info in ${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/images so that one knows what licenses are in use for what image. That would be very convenient when building multiple images with different package content. Rudi
More
Re: pseudo interaction issue Peter Seebach <peter.seebach@...> #5542 Oh, nevermind, I just realized: We use antimagic as the implementation goo for PSEUDO_DISABLED. So a call to os.popen() from a program which has PSEUDO_DISABLED set is going to think it's in antimagic mode. And suddenly, the trick is revealed: os.popen() is bypassing all the runqueue stuff which is trying to ensure that the environment is in a valid state. So if bitbake code calls os.popen(), it may behave weirdly, for the same reason that any other direct invocation of fork() or system() or whatnot would behave weirdly -- because bitbake is running with pseudo in a strange state. So I think the thing is: Because bitbake is running with PSEUDO_DISABLED, any child process that is not explicitly set to either enable or unload pseudo is going to be running under pseudo, with PSEUDO_DISABLED. And that means we need to ensure that PSEUDO_PREFIX stays set, because we need that even when pseudo is disabled. (It's used during some of the initial setup sanity checks.) -s -- Listen, get this. Nobody with a good compiler needs to be justified.
More
Re: pseudo interaction issue Peter Seebach <peter.seebach@...> #5541 On Sat, 24 Mar 2012 17:15:15 +0000 Richard Purdie <richard.purdie@...> wrote: What puzzles me is we get this value from envbackup[key] = os.environ.get("PSEUDO_PREFIX") so its already not in the environment. So basically if we read "PSEUDO_PREFIX" from the environment we get nothing. If we unset the value back to being "nothing", things break. Yes. This is, of course, obviously impossible. Hmm. Well, hmm. When we start up, we should pick up PSEUDO_PREFIX from our environment, and during some of the initial client setup, we should be stashing that value in our stashed values table. At this point, so far as I can tell, nothing should ever unset that stashed value. On fork(), we don't change anything until we're in the client side of the fork, but that setup should happen in the same address space, with the values still stashed. I did find one other thing, though, which worries me. I added a popen() wrapper, and the thing is. We're calling popen() with the "antimagic" bit set (the one that suppresses all the wrappers). Which would cause all sorts of problems, and I can't figure out how it'd be happening. So my new theory: * There's something specific causing us to end up invoking popen() with the antimagic bit set. This is obviously impossible. * But that means that, even if we trap other syscalls made by popen(), we won't be doing wrappers or fixups. * And that could expose problems to do with PSEUDO_PREFIX getting unset unexpectedly. So I think adding it to BB_ENV_EXTRAWHITE will hide this, but it won't explain how we're getting into a popen() call in antimagic mode. (Antimagic is the internal thing pseudo uses while trying to do client/server communications. Pretty sure it never calls popen.) -s -- Listen, get this. Nobody with a good compiler needs to be justified.
More
Re: tentative list of vars to be dropped from variable glossary Rudolf Streif <rudolf.streif@...> #5540 Another variable that seems to be dropped from the latest 1.1.1 revision of the Reference Manual is BBMASK. In previous versions of the manual it was explained that this variable can be used to remove packages from images. However, that did not work for me and it did not surprise me either. To include a package with an image you will have to make it a dependency of that image. If you then hide the recipe of the package using BBMASK then you are breaking the dependency and the Bitbake will complain with "Nothing provides <package>" because the dependency is still there. I could not think of any other use case for BBMASK in the way it is implemented. Are there any? Rudi
More
Re: pseudo interaction issue Peter Seebach <peter.seebach@...> #5539 On Mon, 26 Mar 2012 17:47:29 +0100 Richard Purdie <richard.purdie@...> wrote: This is pretty much what we do at the moment, it gets unset after we load. Pseudo is of course disabled at this point. I guess we just got lucky to this point and avoided "Bad Things"? I suspect so. What's weird to me is that PSEUDO_PREFIX wasn't in the environment before, either. So I still don't quite get this. I am still missing something which will make this all make sense. ... at this point, I am leaning towards viewing this as a bug where it is not enough to simply correct the behavior, I will not feel confident in it until I have understood how it could have happened, but worked in many other cases. -s -- Listen, get this. Nobody with a good compiler needs to be justified.
More
Re: pseudo interaction issue Richard Purdie #5536 On Mon, 2012-03-26 at 11:44 -0500, Peter Seebach wrote: On Sat, 24 Mar 2012 17:41:43 +0000 Richard Purdie <richard.purdie@...> wrote: One or the other of the above on their own doesn't do this. Funky. That's very strange. I wouldn't have expected LOCALSTATEDIR to have any effect either way; it might change how pseudo runs, but it shouldn't affect whether it's being enabled. If we are starting with pseudo loaded, I'm pretty sure it's unsafe to unset PSEUDO_PREFIX ever. After a fork(), pseudo will still be in memory, and if PSEUDO_PREFIX is unset, Bad Things Happen. This is pretty much what we do at the moment, it gets unset after we load. Pseudo is of course disabled at this point. I guess we just got lucky to this point and avoided "Bad Things"? Cheers, Richard
More All Messages By This Member
Re: pseudo interaction issue Peter Seebach <peter.seebach@...> #5535 On Sat, 24 Mar 2012 17:41:43 +0000 Richard Purdie <richard.purdie@...> wrote: One or the other of the above on their own doesn't do this. Funky. That's very strange. I wouldn't have expected LOCALSTATEDIR to have any effect either way; it might change how pseudo runs, but it shouldn't affect whether it's being enabled. If we are starting with pseudo loaded, I'm pretty sure it's unsafe to unset PSEUDO_PREFIX ever. After a fork(), pseudo will still be in memory, and if PSEUDO_PREFIX is unset, Bad Things Happen. -s -- Listen, get this. Nobody with a good compiler needs to be justified.
More
Re: meta-x32: disagreement between ref manual and README.TXT Kamble, Nitin A <nitin.a.kamble@...> #5534 toggle quoted message Show quoted text -----Original Message----- From: yocto-bounces@... [mailto:yocto- bounces@...] On Behalf Of Robert P. J. Day Sent: Sunday, March 25, 2012 9:17 AM To: Yocto discussion list Subject: [yocto] meta-x32: disagreement between ref manual and README.TXT poky ref manual reads: "As usual, use BitBake to build an image that supports the x32 psABI. Here is an example: $ bitake core-image-sato As usual, run your image using QUEM [sic]: $ runqemu qemux86-64 core-image-sato" while the README.TXT file that comes with the experimental/meta-x32 layer reads: "build bitbake core-image-minimal-x32 4. boot the image runqemu qemux86-64 core-image-minimal-x32" thoughts? rday Hi Robert, It is not a significant difference. Images with -x32 in their names contain an additional utility named file. Which can let one check the file types of elf binaries. And the absence of this file utility does not affect functionality of x32 images. Thanks, Nitin
More
Re: can all of the licensing discussion be centralized in an appendix? Tom Zanussi <tom.zanussi@...> #5533 On Mon, 2012-03-26 at 14:26 +0000, Rifenbark, Scott M wrote: Is BSP licensing different than non-BSP licensing? If not, then licensing could be combined into a single section. Can someone answer this for me? The focus of those sections are different and should probably be in separate sections - the BSP licensing section of the BSP Guide deals mainly with the licensing considerations affecting BSP images, while the rest of the Manual deals with the nuts and bolts of how to deal with licenses when writing recipes. Also, good point on the BSP guide appearing as a chapter in the reference manual. I have not liked this. Is there any rational reason to have it this way? I guess it's there for convenience, but the only reason I can see for keeping it there other than that is that it's the only chapter that deals with the kernel. It would probably make sense would be to remove everything in the the BSP Guide from the reference manual, except for the kernel section, which should stay since it's of general interest and not just to people dealing with BSPs. Does that make sense? Tom Scott -----Original Message----- From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Robert P. J. Day Sent: Monday, March 26, 2012 5:53 AM To: Yocto discussion list Subject: [yocto] can all of the licensing discussion be centralized in an appendix? still clawing my way through the ref manual and it seems that there's way too much coverage of licensing sprinkled throughout. most people are not going to care about licensing until the time comes to maybe start distributing their BSP. as it stands, in the development version of the ref manual, section 3.4 is all about licensing, then ch 4 is essentially the BSP guide where section 4.2.1 is "License Files" and all of section 4.3 is "BSP Licensing Considerations." that just seems like too much licensing info that breaks up the flow of the reference manual. can all of that be moved to one location and referenced from there? rday p.s. i'm also not keen on an entire chapter of the ref manual being nothing more than an include of the BSP guide. if you've got a perfectly respectable BSP guide, there's no point having it magically appear as part of another manual. but that's just my $0.02.
More
[PATCH 14/14] meta-cedartrail: change libva license to MIT rahul.saxena@... #5562 From: Rahul Saxena <rahul.saxena@...> The license type in libva recipe was incorrect. Changed it to MIT Signed-off-by: Rahul Saxena <rahul.saxena@.intel.com> --- .../recipes-multimedia/libva/libva_1.0.15.bb \| 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb b/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb index 2800464..3a4cb0c 100644 --- a/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb +++ b/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb @@ -1,9 +1,9 @@ require libva.inc -LICENSE = "CC-BY-3.0" -LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/CC-BY-3.0;md5=dfa02b5755629022e267f10b9c0a2ab7" +LICENSE = "MIT" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" -PR = R0 +PR = "R0" CDR_TRAIL = "download.meego.com/live/MeeGo:/1.2.0:/CedarTrail:" -- 1.7.4.1
More All Messages By This Member
[PATCH 13/14] meta-cedartrail: update SRC_REV_meta for no-pvr case rahul.saxena@... #5561 From: Rahul Saxena <rahul.saxena@...> SRC_REV_meta for no-pvr case updated to be same as that used for pvr build Signed-off-by: Rahul Saxena <rahul.saxena@.intel.com> --- .../recipes-kernel/linux/linux-yocto_3.0.bbappend \| 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend index 0a05d8b..03c5a27 100755 --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend @@ -16,4 +16,4 @@ SRCREV_machine_pn-linux-yocto_cedartrail ?= "5746120ee0afefd1e28400bea4b74f285bd SRCREV_meta_pn-linux-yocto_cedartrail ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= "5746120ee0afefd1e28400bea4b74f285bd5e59a" -SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= "d588bdafc0d9b4d2386144b7d76a1d379e2d16c0" +SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" -- 1.7.4.1
More All Messages By This Member
[PATCH 00/14][meta-intel] Cover letter for updating meta-cedartrail BSP with PVR Graphics driver rahul.saxena@... #5549 From: Rahul Saxena <rahul.saxena@...> Cover letter for updating the Cedar Trail BSP (meta-cedartrail) with PVR Graphics driver. This patch set updates meta-cedartrail (edison branch) to include Power VR driver for Graphics and Video hardware acceleration. The patches enable BSP build with PVR driver or VESA driver depending upon MACHINE setting in local.conf. In addition the patches add web-webkit, audio and video samples to sato image. The Cedar Trail platform is based on the Cedarview processor (Intel® Atom™ N2600, N2800 and D2700 processor)and Tiger Point Chipset (Intel® NM10 Expres Signed-off-by: Rahul Saxena <rahul.saxena@.intel.com> -- The following changes since commit 31eaee8e24d570207338ada64f2df36cdbd5353d: meta-intel: update SRCREVs (2012-02-22 11:58:38 -0600) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib rsaxena-cedartrailpvrrelease26March http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena-cedartrailpvrrelease26March Rahul Saxena (14): meta-cedartrail: Separate conf files for the Cedar Trail BSP boot cases of with and without pvr driver meta-cedartrail: update BBFILES to include meta-intel/common path meta-cedartrail: update README with instructions for PVR Graphics driver build meta-cedatrail: add recipe for setting audio mixer settings during boot meta-cedartrail: seperate xorg.conf files for pvr and no-pvr cases meta-cedartrail: add Cedar Trail PVR driver meta-cedartrail: update Kernel recipes to add support for pvr driver meta-cedartrail: add libva recipe meta-cedartrail: add recipes to instal audio and video samples meta-cedartrail: update formfactor recipe for pvr and no-pvr case meta-cedartrail: Add web-webkit, audio and video samples to sato image meta-cedartrail: Update SRC_URI in kernel recipe append files to point to linux-yocto_3.0 meta-cedartrail: update SRC_REV_meta for no-pvr case meta-cedartrail: change libva license to MIT meta-cedartrail/README \| 50 +++++++++++- meta-cedartrail/conf/layer.conf \| 4 +- meta-cedartrail/conf/machine/cedartrail-nopvr.conf \| 41 +++++++++ meta-cedartrail/conf/machine/cedartrail.conf \| 15 +++- .../cedartrail-audio/cedartrail-audio.bb \| 30 +++++++ .../cedartrail-audio/cedartrail-audio \| 42 +++++++++ .../formfactor/cedartrail-nopvr/machconfig \| 3 + .../xorg-driver/cdv-graphics-drivers_1.0.bb \| 89 ++++++++++++++++++++ .../xserver-xf86-config/cedartrail-nopvr/xorg.conf \| 26 ++++++ .../xserver-xf86-config/cedartrail/xorg.conf \| 24 ++---- .../linux/linux-yocto-rt_3.0.bbappend \| 16 ++++- .../recipes-kernel/linux/linux-yocto_3.0.bbappend \| 17 +++- .../ogg-CC-BY-3.0-music-samples_0.1.bb \| 20 +++++ .../video-samples/bigbuckbunny-ogg.bb \| 20 +++++ meta-cedartrail/recipes-multimedia/libva/libva.inc \| 59 +++++++++++++ .../recipes-multimedia/libva/libva_1.0.15.bb \| 31 +++++++ .../images/core-image-sato-dev.bbappend \| 3 + .../images/core-image-sato-sdk.bbappend \| 3 + .../recipes-sato/images/core-image-sato.bbappend \| 3 + 19 files changed, 468 insertions(+), 28 deletions(-) create mode 100644 meta-cedartrail/conf/machine/cedartrail-nopvr.conf create mode 100644 meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio.bb create mode 100644 meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio/cedartrail-audio create mode 100644 meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail-nopvr/machconfig mode change 100755 => 100644 meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail/machconfig create mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-graphics-drivers_1.0.bb create mode 100644 meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail-nopvr/xorg.conf mode change 100755 => 100644 meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf create mode 100644 meta-cedartrail/recipes-mediasamples/music-samples/ogg-CC-BY-3.0-music-samples_0.1.bb create mode 100644 meta-cedartrail/recipes-mediasamples/video-samples/bigbuckbunny-ogg.bb create mode 100644 meta-cedartrail/recipes-multimedia/libva/libva.inc create mode 100644 meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato-dev.bbappend create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato-sdk.bbappend create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato.bbappend -- 1.7.4.1
More All Messages By This Member

54561 - 54580 of 60126

Home Hashtags Subgroups Terms