Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch
Hi Jessica Zhang, Jessica wrote, On 24.06.2013 07:25: Hi Timo, For case 1, I think we probably should bring back the grey out option. In my opinion, it's more consistent. The property window should be the centralized place for user to setup the settings. The drop down list is for user to quickly toggle between the different settings. So the behavior should be: If there's no project specific settings, that option will be greyed out. I don't think it'll make it secondary as long as it's still visible. Once user 1st time check the project specific setting in the project properties window, we copy the prior profile settings as start point then the user can further customize if there's the need. Once a project has its own specific settings, the option will be enabled in the drop down list and the selection will be consistent between the drop down list selection and project properties settings. What do you think? I get your point. I'll kick out the last patch to restore the greyed out version. I tried to reproduce case 3. And I haven't been able to bring the menu to a state where two menu items are checked. I tried all sorts of combinations without success. Could you maybe tell me the exact steps on how you get this behaviour? However, when trying the different options I realized that there's a bug in the project preferences. Maybe you've already pointed it out and I didn't get it. But if you've configured a project specific profile and change to a target profile, when you enable the project specific profile again, your settings are lost. Instead the selected profile is copied all of the time, instead of only at the first time of configuration. I'll send a fix and a v3 of the menu with the greyed out menu item. Jessica -Original Message- From: Timo Mueller [mailto:m...@timomueller.eu] Sent: Sunday, June 23, 2013 1:36 AM To: Zhang, Jessica Cc: yocto@yoctoproject.org; Timo Mueller Subject: Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch Hi Jessica, Am 21.06.2013 23:47, schrieb Zhang, Jessica: Hi Timo, So what's the purpose of Project Specific Settings, my understanding is it's something that only local to project instead of global name space, e.g. profile? Yes, that's the main idea. OK, I've played a little bit of toggling between profiles, and project specific setting and notice the following behaviors that can be confusing: 1. As your preference that user can specify project specific settings. I've noticed for this case, if I haven't entered any project specific settings via the preference wizard, it'll always copy the profile settings prior to its selection, then in this case I don't think it makes much sense since we already have the profiles to cover all the settings That's independent of this patch set, right? The original idea behind copying the settings of the currently selected profile was to give the user a starting point for creating the project specific settings. The assumption was that the user most of the times only does small modifications to an existing profile. Sure, if the user doesn't alter the settings, the project specific ones match an already defined target profile. One difference remains, if he changes the target profile it will update all projects that use this profile. The project that is using it's own configuration won't be changed, although the settings are similar. An alternative to copying the inital settings would be to blank out the form, when the checkbox is checked. If the assumption is not correct and we think that this is easier to understand for the user, I'll provide a patch set changing this behaviour. 2. OK, now let's move to the case of that I do have explicit setup a project specific settings in the project property view apply it and exit the window. After that, in the drop down list, when I toggle between the options, e.g. I have two profiles besides the project specific settings, then every time after I made the selection and check in the project properties view, the settings matches my selection. So this is good and consistent behavior. 3. If inside the project properties window, I uncheck the Use project specific settings box, and select a profile then apply the changes close the window. Now in the drop down list I will see both the project specific setting and the selected profile are selected. Then next time when I go back, and re-check Use project specific settings box, my project specific setting will be gone, instead the settings will show as my previous profile settings. That's a bug in my implementation. They should always be in sink as you explained in your second point. Overall, I think we still need to play a little bit more of different setting selections via different approaches, some of the inconsistent behavior can get user lost. Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org
[yocto] [Package Report System]Manual check recipes name list
This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo PackageName Version LastChkVersion LastChkTime Maintainer NoUpgradeReason cups 1.6.1 1.6.0 13 days Saul Wold s...@linux.intel.co...No data libpng12 1.2.50 N/A 14 days No Maintainer info No data minicom 2.6.2 2.6.2 14 days Cristian Iorga cristian.iorg...No data Manual Check Count: 3 Manual Need Check Count: 0 Any problem, please contact Saul Wold s...@linux.intel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Package Report System]Upgrade recipes name list
This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-xxx in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-xxx = Not upgrade to 2.0 because the new version is unstable You can check the detail information at http://packages.yoctoproject.org/upgradepkgname PackageName Version UpVersion MaintainerNoUpgradeReason lsb 4.1 1.4 Yi Zhao yi.z...@windriver.com ccache3.1.8 3.1.9 Wenzong Fan wenzong@windriver.com gettext 0.18.20.18.2.1 Wenzong Fan wenzong@windriver.com systemtap-uprobes 2.1+gitAUTOINC+addec81 2.2.1+gitAUTOINC+b1c0ba9 Tom Zanussi tom.zanu...@intel.com swabber-native0.0+gitAUTOINC+a079239 0.0+gitAUTOINC+2d1fe36Saul Wold s...@linux.intel.com libusb-compat 0.1.4 0.1.5 Saul Wold s...@linux.intel.com lsbinitscripts9.46 9.47 Saul Wold s...@linux.intel.com acl 2.2.512.2.52 Saul Wold s...@linux.intel.com mkelfimage1.0.0+svn6637 5914 Saul Wold s...@linux.intel.com libidn1.26 1.27 Saul Wold s...@linux.intel.com nspr 4.9.6 4.10 Saul Wold s...@linux.intel.com kconfig-frontends 3.9.0 3.9.0.0 Saul Wold s...@linux.intel.com glib-networking 2.36.22.37.2 Saul Wold s...@linux.intel.com docbook-sgml-dtd-4.1-native 1.0 41 Saul Wold s...@linux.intel.com docbook-sgml-dtd-3.1-native 1.0 31 Saul Wold s...@linux.intel.com createrepo0.4.110.9.9 Saul Wold s...@linux.intel.com Versions after 0.9.* use YUM,... guilt-native 0.33 0.35 Saul Wold s...@linux.intel.com gtk-doc-stub 0.0+gitAUTOINC+3dfd0a0 0.0+gitAUTOINC+3dfd0a0Saul Wold s...@linux.intel.com help2man-native 1.41.21.43.2 Saul Wold s...@linux.intel.com vte 0.28.20.34.6 Saul Wold s...@linux.intel.com libxkbcommon 0.3.0 0.3.1 Saul Wold s...@linux.intel.com sysstat 10.1.510.1.6 Saul Wold s...@linux.intel.com cracklib 2.8.222.9.0 Saul Wold s...@linux.intel.com oprofileui-server 0.0+gitAUTOINC+f168b8b 0.0+gitAUTOINC+f168b8bSaul Wold s...@linux.intel.com texinfo 4.13a 5.1 Saul Wold s...@linux.intel.com Checking script parses direct... build-appliance-image 8.0 9.0.0 Saul Wold s...@linux.intel.com socat 1.7.2.1 1.7.2.2 Saul Wold s...@linux.intel.com http://www.dest-unreach.org/socat/download/socat-1.7.2.1.tar.bz2;name=src sato-screenshot 0.1+gitAUTOINC+c792e4e 0.1+gitAUTOINC+c792e4eSaul Wold s...@linux.intel.com docbook-sgml-dtd-4.5-native 1.0 4.5 Saul Wold s...@linux.intel.com attr 2.4.462.4.47
Re: [yocto] linux-yocto-rt and cgroups
From: Bruce Ashfield There's no technical reason at all. In fact, pre 3.8 the -rt kernel used to inherit more of the standard kernel's configuration and hence enabled cgroups. In 3.8, we defined a new policy for the -rt kernel, that used parts of the standard kernel's configuration, but not all. We can definitely add functionality to this baseline, and I'll be adding more in the upcoming dev cycle for yocto 1.5. In the meantime you can enable it, and let me know how it goes. I can then update the -rt baseline config, knowing that someone else is testing it too. To enable it, create a linux-yocto_3.8.bbappend, and add: KERNEL_FEATURES_append = features/cgroups/cgroups.scc And you'll get the same cgroups config that you have with the standard linux-yocto kernel. Yes, that builds and boots fine (except it's linux-yocto-rt_3.8.bbappend). Thanks a million. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How NOT to include kernel image to the rootfs?
Hi, Thank you for the answer. I've tried - by commenting RDEPENDS_kernel-base ?= kernel-image from kernel.bbclass - and/or adding RDEPENDS_kernel-base = in my image definition But neither worked. For confirmation, this bitbake -e outptut and it doesn't have the kernel-base insop@neon /opt/build-fsl-yocto-1.3.2 $ time bitbake -e fsl-image-min-net2 | grep kernel-base real 0m10.691s user 0m6.476s sys 0m0.844s insop@neon /opt/bui Also, though it was not concluded, I found this mail thread also said that it didn't work http://comments.gmane.org/gmane.linux.embedded.yocto.general/12694 Any other thought? Thank you, Insop On Sun, Jun 23, 2013 at 8:29 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-06-23 7:08 PM, Insop Song wrote: Hi, - Question How NOT to include kernel image to the rootfs? - Background In our application, we use u-boot to load kernel and rootfs from nand flash separately. I don't want to include kernel image inside /boot as I don't need it over there. I could untar the rootfs, remove, and tar it up again, but I would like to find a way within the yocto framework. I was not able to find a way by looking up the recipies and googling on this topic. Could any one help me? Have you tried clearing RDEPENDS_kernel-base ? From kernel.bbclass: # Allow machines to override this dependency if kernel image files are # not wanted in images as standard RDEPENDS_kernel-base ?= kernel-image Cheers, Bruce Thank you, Insop ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How NOT to include kernel image to the rootfs?
On Mon, Jun 24, 2013 at 5:29 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-06-23 7:08 PM, Insop Song wrote: Hi, - Question How NOT to include kernel image to the rootfs? - Background In our application, we use u-boot to load kernel and rootfs from nand flash separately. I don't want to include kernel image inside /boot as I don't need it over there. I could untar the rootfs, remove, and tar it up again, but I would like to find a way within the yocto framework. I was not able to find a way by looking up the recipies and googling on this topic. Could any one help me? Have you tried clearing RDEPENDS_kernel-base ? From kernel.bbclass: # Allow machines to override this dependency if kernel image files are # not wanted in images as standard RDEPENDS_kernel-base ?= kernel-image please look at this machine configuration file that we use at Linaro: https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=blob;f=meta-linaro/conf/machine/genericarmv7a.conf;h=d2577f69868d599f114063a7c6a3d8d0a93c532b;hb=c383e63617469dce76411249dba384aad21a3d9c we use such 'generic' machines to build our 'generic' ARM rootfs. the trick is indeed: # Don't include kernels in standard images RDEPENDS_kernel-base = Cheers, Bruce Thank you, Insop __**_ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How NOT to include kernel image to the rootfs?
* Insop Song insop.s...@gmail.com [130624 10:56]: I've tried - by commenting RDEPENDS_kernel-base ?= kernel-image from kernel.bbclass - and/or adding RDEPENDS_kernel-base = in my image definition You should add this line in either your local.conf, or in a .bbappend for the kernel recipe in question. But neither worked. That should make it work. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How NOT to include kernel image to the rootfs?
Insop, You can check the actual dependency in the output file of bitbake -g fsl-image-min-net2. Best Regards, Zhenhua -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Anders Darander Sent: Monday, June 24, 2013 5:05 PM To: yocto@yoctoproject.org Subject: Re: [yocto] How NOT to include kernel image to the rootfs? * Insop Song insop.s...@gmail.com [130624 10:56]: I've tried - by commenting RDEPENDS_kernel-base ?= kernel-image from kernel.bbclass - and/or adding RDEPENDS_kernel-base = in my image definition You should add this line in either your local.conf, or in a .bbappend for the kernel recipe in question. But neither worked. That should make it work. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How NOT to include kernel image to the rootfs?
Thank you all for the help. I've added RDEPENDS_kernel-base = at conf/local.conf Also I had to take out oprofile in my image, as oprofile needs kernel-vmlinux ... Then it worked. Thank you all. Regards, Insop On Mon, Jun 24, 2013 at 2:12 AM, Luo Zhenhua-B19537 b19...@freescale.com wrote: Insop, You can check the actual dependency in the output file of bitbake -g fsl-image-min-net2. Best Regards, Zhenhua -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Anders Darander Sent: Monday, June 24, 2013 5:05 PM To: yocto@yoctoproject.org Subject: Re: [yocto] How NOT to include kernel image to the rootfs? * Insop Song insop.s...@gmail.com [130624 10:56]: I've tried - by commenting RDEPENDS_kernel-base ?= kernel-image from kernel.bbclass - and/or adding RDEPENDS_kernel-base = in my image definition You should add this line in either your local.conf, or in a .bbappend for the kernel recipe in question. But neither worked. That should make it work. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail
On Mon, Jun 24, 2013 at 1:41 AM, Rudolf Streif rstr...@linuxfoundation.org wrote: Hi Trever et al: If I were writing a book about Yocto/OE, This is a project I am currently working on, a book about the Yocto Project. The goal is to enable readers to do practical projects with YP. As the subject matter for the project described in the book I have chosen a home automation project. Reason being, it interests me personally and it uses different devices such as a UI-less controller, remotes with touch screens etc. I have gotten a lot of feedback from the YP training class I have developed and been teaching for the Linux Foundation. I am putting this out here to solicit more feedback from the community on what you think a book on YP should include. For instance as an advanced topic I included a chapter on how to run YP on AWS EC2 and I will be adding Autobuilder to it too. in the first chapter I would have the readers build their own filesystem/kernel from scratch (I can't decide if I would also have them build their own cross-compiler from scratch or if I'd cheat and let them use crosstool-NG). I thought about that too but I found it distracting. It's like let me show you the hard way with crosstool-ng and buildroot and then I show you a better way with YP. What I am doing though is an intro into Bitbake: how to use just Bitbake to build something. That proved valuable during the training classes. It's like a HelloWorld (and I published that before on this mailing list) introducing the concepts of Bitbake with it's layers, recipes, syntax etc. FWIW, I'm incorporating a HelloWorld chapter into the new BitBake manual. It builds on your post of the same that you made to the mailing list. Cheers, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail
Hi Rudi, On 24 June 2013 01:41, Rudolf Streif rstr...@linuxfoundation.org wrote: If I were writing a book about Yocto/OE, This is a project I am currently working on, a book about the Yocto Project. Awesome! That's great news! I was hoping someone would beat me to it :-) I look forward to reading it once it's done. Do you have a publisher or an expected release date? An appendix on Android's repo tool might make for an excellent addition; it seems some Yocto projects are showing lots of interest in using it. in the first chapter I would have the readers build their own filesystem/kernel from scratch I thought about that too but I found it distracting. Fair enough. Maybe I'll write some blog-ish post about it for those rare few who would like to see a bottom-up perspective :-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
Scott, I think the general diagram looks pretty good, although I'd argue there's a little too much detail in the file list being shown, or else some of this new stuff is going to be useful in 1.5 when it's not doing anything in 1.4. Here are the files I see as excessive: In meta-yocto: - local.conf.example.extended - site.conf.sample - auto.conf (That's not even present in my 1.4 workspace. Is this going to be something new in 1.5?) In the build directory (these files aren't even present for me in 1.4): - site.conf - auto.conf Also, I don't see anything specifying machines. Do you want to break that out here, or are you thinking that's going to come into play somewhere else? If you're thinking of breaking out machines elsewhere, I'd argue that distros are on a similar level of detail and then also don't belong on this chart. Kind regards, Jerrod On Sun, Jun 23, 2013 at 11:52 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: Hi, I am going to start throwing these diagrams out to the mailing list and see if I can get any feedback. This attached figure dives into user configuration. Any and all discussion, correction, suggestions are welcome. Scott -Original Message- From: Rifenbark, Scott M Sent: Friday, June 21, 2013 1:22 AM To: Paul Eggleton; Burton, Ross Subject: user configuration Paul and Ross, Attached is a sample figure that focuses on User Configuration. The illustration attempts to reveal where user configuration data comes from and what processes and user-driven commands are related to it. Right now, BitBake is simply a box. If you can, give me some comments on this. I would like to hear on level of detail as well as technical accuracy. Thanks, Scott Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto-rt and cgroups
On 13-06-24 03:09 AM, Paul D. DeRocco wrote: From: Bruce Ashfield There's no technical reason at all. In fact, pre 3.8 the -rt kernel used to inherit more of the standard kernel's configuration and hence enabled cgroups. In 3.8, we defined a new policy for the -rt kernel, that used parts of the standard kernel's configuration, but not all. We can definitely add functionality to this baseline, and I'll be adding more in the upcoming dev cycle for yocto 1.5. In the meantime you can enable it, and let me know how it goes. I can then update the -rt baseline config, knowing that someone else is testing it too. To enable it, create a linux-yocto_3.8.bbappend, and add: KERNEL_FEATURES_append = features/cgroups/cgroups.scc And you'll get the same cgroups config that you have with the standard linux-yocto kernel. Yes, that builds and boots fine (except it's linux-yocto-rt_3.8.bbappend). Hah. Indeed! Thanks a million. Great news. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On 06/23/2013 11:52 PM, Rifenbark, Scott M wrote: Hi, I am going to start throwing these diagrams out to the mailing list and see if I can get any feedback. This attached figure dives into user configuration. Any and all discussion, correction, suggestions are welcome. It appears the diagram says that the oe-init-build-env script creates the files in the users conf dir from the meta-yocto layer. These files (and the script) are in meta. This diagram creates the misleading idea that the meta-yocto layer is mandatory in order to create a working build. Philip Scott -Original Message- From: Rifenbark, Scott M Sent: Friday, June 21, 2013 1:22 AM To: Paul Eggleton; Burton, Ross Subject: user configuration Paul and Ross, Attached is a sample figure that focuses on User Configuration. The illustration attempts to reveal where user configuration data comes from and what processes and user-driven commands are related to it. Right now, BitBake is simply a box. If you can, give me some comments on this. I would like to hear on level of detail as well as technical accuracy. Thanks, Scott Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On 24 June 2013 13:59, Jerrod Peach pea...@lexmark.com wrote: auto.conf (That's not even present in my 1.4 workspace. Is this going to be something new in 1.5?) auto.conf is read along with site.conf and local.conf, and is intended to be automatically created and maintained by autobuilders. That's why you don't have it locally. (I only discovered about this file when we were talking about inputs last week) Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
Jerrod, Thanks for the feedback in this area. Your observations are pretty much in line with what I got from Paul Eggleton, who is on the YP Team. I am going to reduce what is revealed file-wise in the meta-yocto layer. Turns out that auto.conf and site.conf are files that a user would have to hand-create if they even wanted them. We happen to provide a sample for site.conf only. The auto.conf file would be a file that could be created and written to by an autobuilder. The auto.conf file could contain settings that would be similar to what you would see in a local.conf file. My understanding is that it exists mainly for autobuilders to stuff things into. I will note this in the section I'm developing here for this configuration stuff. Machine, distro, and policies and all that type of configuration is going to be covered in my next little submission that talks about layers and their role regarding what they feed into the whole process. Thanks, Scott From: Jerrod Peach [mailto:pea...@lexmark.com] Sent: Monday, June 24, 2013 6:00 AM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Documenting YP Development Environment in more detail - user configuration Scott, I think the general diagram looks pretty good, although I'd argue there's a little too much detail in the file list being shown, or else some of this new stuff is going to be useful in 1.5 when it's not doing anything in 1.4. Here are the files I see as excessive: In meta-yocto: * local.conf.example.extended * site.conf.sample * auto.conf (That's not even present in my 1.4 workspace. Is this going to be something new in 1.5?) In the build directory (these files aren't even present for me in 1.4): * site.conf * auto.conf Also, I don't see anything specifying machines. Do you want to break that out here, or are you thinking that's going to come into play somewhere else? If you're thinking of breaking out machines elsewhere, I'd argue that distros are on a similar level of detail and then also don't belong on this chart. Kind regards, Jerrod On Sun, Jun 23, 2013 at 11:52 PM, Rifenbark, Scott M scott.m.rifenb...@intel.commailto:scott.m.rifenb...@intel.com wrote: Hi, I am going to start throwing these diagrams out to the mailing list and see if I can get any feedback. This attached figure dives into user configuration. Any and all discussion, correction, suggestions are welcome. Scott -Original Message- From: Rifenbark, Scott M Sent: Friday, June 21, 2013 1:22 AM To: Paul Eggleton; Burton, Ross Subject: user configuration Paul and Ross, Attached is a sample figure that focuses on User Configuration. The illustration attempts to reveal where user configuration data comes from and what processes and user-driven commands are related to it. Right now, BitBake is simply a box. If you can, give me some comments on this. I would like to hear on level of detail as well as technical accuracy. Thanks, Scott Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702tel:503.712.2702 503.341.0418tel:503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
What I was trying to convey here is that oe-init-build-env draws on some files in the meta-yocto layer. The script oe-init-build-env is in the poky repository (or refered to as Source Directory in the documentation). The sample files are in the meta-yocto layer. I thought the meta-yocto layer was needed... maybe I am wrong. Can I get more clarification on this? Thanks, Scott -Original Message- From: Philip Balister [mailto:phi...@balister.org] Sent: Monday, June 24, 2013 6:15 AM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Documenting YP Development Environment in more detail - user configuration On 06/23/2013 11:52 PM, Rifenbark, Scott M wrote: Hi, I am going to start throwing these diagrams out to the mailing list and see if I can get any feedback. This attached figure dives into user configuration. Any and all discussion, correction, suggestions are welcome. It appears the diagram says that the oe-init-build-env script creates the files in the users conf dir from the meta-yocto layer. These files (and the script) are in meta. This diagram creates the misleading idea that the meta-yocto layer is mandatory in order to create a working build. Philip Scott -Original Message- From: Rifenbark, Scott M Sent: Friday, June 21, 2013 1:22 AM To: Paul Eggleton; Burton, Ross Subject: user configuration Paul and Ross, Attached is a sample figure that focuses on User Configuration. The illustration attempts to reveal where user configuration data comes from and what processes and user-driven commands are related to it. Right now, BitBake is simply a box. If you can, give me some comments on this. I would like to hear on level of detail as well as technical accuracy. Thanks, Scott Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Image recipes in Yocto 1.4 (dylan-9.0.0)
Hi, I apologize in advance if I'm not posting this to correct place or in the correct manner. I have a question regarding the shared state code optimizations in yocto 1.4. I'm in the process of upgrading one of our projects from Edison (6.0) to Dylan (9.0.0) and am running into an issue with our existing image recipe. The recipe brings in files from a files directory in the image area. It also adds an image preprocess command that takes action on those files in the work area. After reading the version 1.4 migration guidelines and examining both the old and new builds, it looks like the do_unpack task has been optimized out of the way images are built in the new release. The files listed in the SRC_URI variable don't get populated in the work directory, and actions taken in the image preprocess command fail. Is there a way to stop this optimization and have the image build populate the work directory as it has in the past? Thank you, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
My figure is for Yocto Project documentation so I am going to show that oe-init-build-env gets information from meta-yocto. I understand that OE-Core sample files are in meta. There is a single oe-init-build-env script and it looks in one of two places. Scott -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, June 24, 2013 7:57 AM To: Robert P. J. Day Cc: Rifenbark, Scott M; yocto@yoctoproject.org Subject: Re: [yocto] Documenting YP Development Environment in more detail - user configuration On 24 June 2013 15:47, Robert P. J. Day rpj...@crashcourse.ca wrote: On Mon, 24 Jun 2013, Rifenbark, Scott M wrote: What I was trying to convey here is that oe-init-build-env draws on some files in the meta-yocto layer. The script oe-init-build-env is in the poky repository (or refered to as Source Directory in the documentation). The sample files are in the meta-yocto layer. I thought the meta-yocto layer was needed... maybe I am wrong. Can I get more clarification on this? i regularly build images without any *yocto*-named layer, unless i'm misunderstanding the issue here. meta-yocto is what makes Poky Poky, otherwise it would be just oe-core + bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF, which is one of the things that get munged as bitbake+oe-core+meta-yocto becomes poky. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote: What I was trying to convey here is that oe-init-build-env draws on some files in the meta-yocto layer. The script oe-init-build-env is in the poky repository (or refered to as Source Directory in the documentation). The sample files are in the meta-yocto layer. I thought the meta-yocto layer was needed... maybe I am wrong. Can I get more clarification on this? i regularly build images without any *yocto*-named layer, unless i'm misunderstanding the issue here. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On 24 June 2013 15:47, Robert P. J. Day rpj...@crashcourse.ca wrote: On Mon, 24 Jun 2013, Rifenbark, Scott M wrote: What I was trying to convey here is that oe-init-build-env draws on some files in the meta-yocto layer. The script oe-init-build-env is in the poky repository (or refered to as Source Directory in the documentation). The sample files are in the meta-yocto layer. I thought the meta-yocto layer was needed... maybe I am wrong. Can I get more clarification on this? i regularly build images without any *yocto*-named layer, unless i'm misunderstanding the issue here. meta-yocto is what makes Poky Poky, otherwise it would be just oe-core + bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF, which is one of the things that get munged as bitbake+oe-core+meta-yocto becomes poky. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image recipes in Yocto 1.4 (dylan-9.0.0)
Hi Brian,
On Monday 24 June 2013 11:01:31 Brian Karcz wrote:
I have a question regarding the shared state code optimizations in yocto
1.4. I'm in the process of upgrading one of our projects from Edison (6.0)
to Dylan (9.0.0) and am running into an issue with our existing image
recipe.
The recipe brings in files from a files directory in the image area. It
also adds an image preprocess command that takes action on those files in
the work area. After reading the version 1.4 migration guidelines and
examining both the old and new builds, it looks like the do_unpack task has
been optimized out of the way images are built in the new release. The
files listed in the SRC_URI variable don't get populated in the work
directory, and actions taken in the image preprocess command fail.
Is there a way to stop this optimization and have the image build populate
the work directory as it has in the past?
You should be able to do this in your image recipe:
python () {
d.delVarFlag(do_fetch, noexec)
d.delVarFlag(do_unpack, noexec)
}
This isn't related to shared state, btw, just that image.bbclass disables
these tasks by default as of version 1.2 (denzil).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] linux-libc-header version mismatch?
Hi. We are using a 3.6 based kernel in our builds using a custom kernel recipe. However, I can see that the linux-libc-headers built but based on a 3.8 kernel? Is this really how it should be? Are we supposed to also make a custom recipe for the linux-libc-headers? The image seems to be executing fine but I am a bit worried about the version mismatch :( Hans PS. I believe I posted this question before but I am no longer 100% convinced it actually left my outbox. At least I never got a response, which usually happens very quickly :) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch
Hi Timo, Your finding is described in my case 3. For reproduce the double selection, you need to select project specific apply exit the property window. Then go back to property window, deselect project specific apply, exit the window. Then check the drop down list, I can consistently reproduce the case this way. Give it a try. Thanks, Jessica -Original Message- From: Timo Müller [mailto:m...@timomueller.eu] Sent: Sunday, June 23, 2013 11:52 PM To: Zhang, Jessica Cc: yocto@yoctoproject.org; Timo Mueller Subject: Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch Hi Jessica Zhang, Jessica wrote, On 24.06.2013 07:25: Hi Timo, For case 1, I think we probably should bring back the grey out option. In my opinion, it's more consistent. The property window should be the centralized place for user to setup the settings. The drop down list is for user to quickly toggle between the different settings. So the behavior should be: If there's no project specific settings, that option will be greyed out. I don't think it'll make it secondary as long as it's still visible. Once user 1st time check the project specific setting in the project properties window, we copy the prior profile settings as start point then the user can further customize if there's the need. Once a project has its own specific settings, the option will be enabled in the drop down list and the selection will be consistent between the drop down list selection and project properties settings. What do you think? I get your point. I'll kick out the last patch to restore the greyed out version. I tried to reproduce case 3. And I haven't been able to bring the menu to a state where two menu items are checked. I tried all sorts of combinations without success. Could you maybe tell me the exact steps on how you get this behaviour? However, when trying the different options I realized that there's a bug in the project preferences. Maybe you've already pointed it out and I didn't get it. But if you've configured a project specific profile and change to a target profile, when you enable the project specific profile again, your settings are lost. Instead the selected profile is copied all of the time, instead of only at the first time of configuration. I'll send a fix and a v3 of the menu with the greyed out menu item. Jessica -Original Message- From: Timo Mueller [mailto:m...@timomueller.eu] Sent: Sunday, June 23, 2013 1:36 AM To: Zhang, Jessica Cc: yocto@yoctoproject.org; Timo Mueller Subject: Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch Hi Jessica, Am 21.06.2013 23:47, schrieb Zhang, Jessica: Hi Timo, So what's the purpose of Project Specific Settings, my understanding is it's something that only local to project instead of global name space, e.g. profile? Yes, that's the main idea. OK, I've played a little bit of toggling between profiles, and project specific setting and notice the following behaviors that can be confusing: 1. As your preference that user can specify project specific settings. I've noticed for this case, if I haven't entered any project specific settings via the preference wizard, it'll always copy the profile settings prior to its selection, then in this case I don't think it makes much sense since we already have the profiles to cover all the settings That's independent of this patch set, right? The original idea behind copying the settings of the currently selected profile was to give the user a starting point for creating the project specific settings. The assumption was that the user most of the times only does small modifications to an existing profile. Sure, if the user doesn't alter the settings, the project specific ones match an already defined target profile. One difference remains, if he changes the target profile it will update all projects that use this profile. The project that is using it's own configuration won't be changed, although the settings are similar. An alternative to copying the inital settings would be to blank out the form, when the checkbox is checked. If the assumption is not correct and we think that this is easier to understand for the user, I'll provide a patch set changing this behaviour. 2. OK, now let's move to the case of that I do have explicit setup a project specific settings in the project property view apply it and exit the window. After that, in the drop down list, when I toggle between the options, e.g. I have two profiles besides the project specific settings, then every time after I made the selection and check in the project properties view, the settings matches my selection. So this is good and consistent behavior. 3. If inside the project properties window, I uncheck the Use project specific settings box, and select a profile then apply the changes close the window. Now in the drop down list
Re: [yocto] linux-libc-header version mismatch?
On 13-06-24 11:59 AM, Hans Beckérus wrote: Hi. We are using a 3.6 based kernel in our builds using a custom kernel recipe. However, I can see that the linux-libc-headers built but based on a 3.8 kernel? Is this really how it should be? Are we supposed to also make a custom recipe for the linux-libc-headers? The image seems to be executing fine but I am a bit worried about the version mismatch :( You shouldn't need to do this. We use a single libc-headers version for all of a given linux-yocto kernels in a release. The userspace / libc ABI is stable, and backwards compatible (generally speaking of course). New interfaces typically have a fallback if the kernel interface is missing, and we don't currently have any issues either. Of course older headers with newer kernels is even safer, since typically at most you are missing out on being able to use new APIs versus potential for missing APIs. Summary: you can match them if you want, but we are testing across several kernel versions and haven't found any issues (yet). Cheers, Bruce Hans PS. I believe I posted this question before but I am no longer 100% convinced it actually left my outbox. At least I never got a response, which usually happens very quickly :) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-libc-header version mismatch?
On 24 June 2013 17:19, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-06-24 11:59 AM, Hans Beckérus wrote: Hi. We are using a 3.6 based kernel in our builds using a custom kernel recipe. However, I can see that the linux-libc-headers built but based on a 3.8 kernel? Is this really how it should be? Are we supposed to also make a custom recipe for the linux-libc-headers? The image seems to be executing fine but I am a bit worried about the version mismatch :( Summary: you can match them if you want, but we are testing across several kernel versions and haven't found any issues (yet). Just to point out - this is pretty common across linux distros as well, otherwise all your software would have to be re-built every time you updated the kernel. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-libc-header version mismatch?
On Mon, Jun 24, 2013 at 6:29 PM, Paul Barker p...@paulbarker.me.uk wrote: On 24 June 2013 17:19, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-06-24 11:59 AM, Hans Beckérus wrote: Hi. We are using a 3.6 based kernel in our builds using a custom kernel recipe. However, I can see that the linux-libc-headers built but based on a 3.8 kernel? Is this really how it should be? Are we supposed to also make a custom recipe for the linux-libc-headers? The image seems to be executing fine but I am a bit worried about the version mismatch :( Summary: you can match them if you want, but we are testing across several kernel versions and haven't found any issues (yet). Just to point out - this is pretty common across linux distros as well, otherwise all your software would have to be re-built every time you updated the kernel. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk Thanks Paul (and Bruce of course). I now realize that this would break most systems after a major kernel upgrade ;) From what I know/experienced so far is that the only thing that usually breaks with a new major kernel version is our own kernel drivers... Hans On Mon, Jun 24, 2013 at 6:29 PM, Paul Barker p...@paulbarker.me.uk wrote: On 24 June 2013 17:19, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-06-24 11:59 AM, Hans Beckérus wrote: Hi. We are using a 3.6 based kernel in our builds using a custom kernel recipe. However, I can see that the linux-libc-headers built but based on a 3.8 kernel? Is this really how it should be? Are we supposed to also make a custom recipe for the linux-libc-headers? The image seems to be executing fine but I am a bit worried about the version mismatch :( Summary: you can match them if you want, but we are testing across several kernel versions and haven't found any issues (yet). Just to point out - this is pretty common across linux distros as well, otherwise all your software would have to be re-built every time you updated the kernel. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On 06/24/2013 11:08 AM, Rifenbark, Scott M wrote: My figure is for Yocto Project documentation so I am going to show that oe-init-build-env gets information from meta-yocto. I understand that OE-Core sample files are in meta. There is a single oe-init-build-env script and it looks in one of two places. Actually, the script is in two places, the root level of a poky checkout and in the oe-core directory. Explaining how poky is built up from oe-core + meta-yocto + meta-yocto-bsp + some other stuff would be really helpful in reducing confusion over what all the pieces are and where they come from. Philip Scott -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, June 24, 2013 7:57 AM To: Robert P. J. Day Cc: Rifenbark, Scott M; yocto@yoctoproject.org Subject: Re: [yocto] Documenting YP Development Environment in more detail - user configuration On 24 June 2013 15:47, Robert P. J. Day rpj...@crashcourse.ca wrote: On Mon, 24 Jun 2013, Rifenbark, Scott M wrote: What I was trying to convey here is that oe-init-build-env draws on some files in the meta-yocto layer. The script oe-init-build-env is in the poky repository (or refered to as Source Directory in the documentation). The sample files are in the meta-yocto layer. I thought the meta-yocto layer was needed... maybe I am wrong. Can I get more clarification on this? i regularly build images without any *yocto*-named layer, unless i'm misunderstanding the issue here. meta-yocto is what makes Poky Poky, otherwise it would be just oe-core + bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF, which is one of the things that get munged as bitbake+oe-core+meta-yocto becomes poky. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On 24 June 2013 17:55, Philip Balister phi...@balister.org wrote: Explaining how poky is built up from oe-core + meta-yocto + meta-yocto-bsp + some other stuff would be really helpful in reducing confusion over what all the pieces are and where they come from. Agreed - explaining clearly that Poky is mostly an aggregation of existing repositories and not actually canonical upstream for anything is probably a good move, as this is clearly misunderstood by many people. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
Ok - I was told there was just a single version of oe-init-build-env. So that must be not quite right. What I will likely do is in the supporting text for the figure get into some detail on just where these pieces are. That would be a good opportunity to maybe present some text around that. -Original Message- From: Philip Balister [mailto:phi...@balister.org] Sent: Monday, June 24, 2013 9:56 AM To: Rifenbark, Scott M Cc: Burton, Ross; Robert P. J. Day; yocto@yoctoproject.org Subject: Re: [yocto] Documenting YP Development Environment in more detail - user configuration On 06/24/2013 11:08 AM, Rifenbark, Scott M wrote: My figure is for Yocto Project documentation so I am going to show that oe-init-build-env gets information from meta-yocto. I understand that OE-Core sample files are in meta. There is a single oe-init- build-env script and it looks in one of two places. Actually, the script is in two places, the root level of a poky checkout and in the oe-core directory. Explaining how poky is built up from oe-core + meta-yocto + meta-yocto-bsp + some other stuff would be really helpful in reducing confusion over what all the pieces are and where they come from. Philip Scott -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, June 24, 2013 7:57 AM To: Robert P. J. Day Cc: Rifenbark, Scott M; yocto@yoctoproject.org Subject: Re: [yocto] Documenting YP Development Environment in more detail - user configuration On 24 June 2013 15:47, Robert P. J. Day rpj...@crashcourse.ca wrote: On Mon, 24 Jun 2013, Rifenbark, Scott M wrote: What I was trying to convey here is that oe-init-build-env draws on some files in the meta-yocto layer. The script oe-init-build-env is in the poky repository (or refered to as Source Directory in the documentation). The sample files are in the meta-yocto layer. I thought the meta-yocto layer was needed... maybe I am wrong. Can I get more clarification on this? i regularly build images without any *yocto*-named layer, unless i'm misunderstanding the issue here. meta-yocto is what makes Poky Poky, otherwise it would be just oe- core + bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF, which is one of the things that get munged as bitbake+oe-core+meta-yocto becomes poky. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On 06/24/2013 12:59 PM, Burton, Ross wrote: On 24 June 2013 17:55, Philip Balister phi...@balister.org wrote: Explaining how poky is built up from oe-core + meta-yocto + meta-yocto-bsp + some other stuff would be really helpful in reducing confusion over what all the pieces are and where they come from. Agreed - explaining clearly that Poky is mostly an aggregation of existing repositories and not actually canonical upstream for anything is probably a good move, as this is clearly misunderstood by many people. Showing how Poky (the reference distribution) is built would be a nice way to introduce people to building their own custom distributions using OpenEmbedded. Philip ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister phi...@balister.org wrote: Showing how Poky (the reference distribution) is built would be a nice way to introduce people to building their own custom distributions using OpenEmbedded. Totally agree, but I would relegate that to a separate effort. The main problem with diagrams like this is trying to squeeze in too much information in order to preserve completeness, at the expense of clarity. It would be more ideal to start with a very simple diagram, then move on to other diagrams to zoom in on pertinent detail. It is a delicate balancing act. In this case, I would say to put how Poky is built into the 3rd or 4th diagram in a series. I'm glad to see this conversation happening! -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project bug trends for 2013 WW25
Thanks for sending these out! Nice to see it before the meeting tomorrow On 6/24/13 11:37 AM, Michael Halstead mich...@yoctoproject.org wrote: The trend graphs for work week 25 are up at https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend with two new charts. Versions of the weighted defect density trend-lines with Yocto Project release dates and several additional controls have been added. Screenshots of the graphs are attached for people who need a copy while offline. These are large images and you may need to open them outside of your e-mail client to see all the detail. -- Michael Halstead Yocto Project / System Administrator ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] The simplest possible recipe
That would be to copy a single file, provided in the files subdirectory of
the recipe, into a particular place in the target tree. Is there any bbclass
that automates this? Or do I just write a recipe with a do_install function
that executes the install command?
My only guide is 5.3.1 in the Development Manual, which performs a simple
compilation, but I'm very hazy about how recipes are interpreted, so I'd
like it if someone can tell me if I've gotten the following stuff right or
not.
SRC_URI tells bitbake what files must be gotten from somewhere and copied
somewhere else in order to carry out the build process. And according to the
Ref Manual, the file:// prefix tells it to fetch a local file by searching
some directories including the files subdirectory next to the .bb file.
And apparently, there is a subdir option (whose syntax is unexplained)
which may be used to tell bitbake to put it somewhere specific relative to
${WORKDIR}.
Is the default value of the subdir option the S variable? Is that the
purpose of S, to tell bitbake where to put things that it fetches? The Ref
Manual says that S defaults to ${WORKDIR}/${PN}/${PV}, but then the sample
compile recipe sets S to ${WORKDIR}. Is that what one does when one doesn't
need to have a bunch of versioned subdirectories under ${WORKDIR}? (I'm not
sure why one would ever want that, or why that would be the default.)
So if I want to install a file somewhere, do I even need a do_install task,
or can I just set S equal to the desired target location, like
${etcdir}/foo and be done with it? Or is that a no-no, and should I always
use do_install?
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail - user configuration
On 06/24/2013 02:37 PM, Jeff Osier-Mixon wrote: On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister phi...@balister.org wrote: Showing how Poky (the reference distribution) is built would be a nice way to introduce people to building their own custom distributions using OpenEmbedded. Totally agree, but I would relegate that to a separate effort. The main problem with diagrams like this is trying to squeeze in too much information in order to preserve completeness, at the expense of clarity. It would be more ideal to start with a very simple diagram, then move on to other diagrams to zoom in on pertinent detail. It is a delicate balancing act. In this case, I would say to put how Poky is built into the 3rd or 4th diagram in a series. I'm glad to see this conversation happening! I totally agree we drifted way beyond the initial discussion of the figure. The key thought here is understanding how Poky differs from a typical use of oe-core + other layers. Philip ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documenting YP Development Environment in more detail
Hi Trevor, On Mon, Jun 24, 2013 at 5:56 AM, Trevor Woerner trevor.woer...@linaro.orgwrote: Awesome! That's great news! I was hoping someone would beat me to it :-) I look forward to reading it once it's done. Do you have a publisher or an expected release date? Yes, I do. Pearson and the release date is early next year (Embedded Linux Conference is my target). An appendix on Android's repo tool might make for an excellent addition; it seems some Yocto projects are showing lots of interest in using it. The idea is to integrate/use it with YP? I know what repo does and that it is built on top of git but I have not looked behind the scenes to figure out how it does its job and how it can be used with something else like YP instead of with the Android repositories and review system. Cheers, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 3/3] meta: add BSP-specific touchscreen support
Add touchscreen-composite support to machines based on common-pc and common-pc-64, along with several other Atom boards that don't inherit from those, thus providing those machines with the out-of-the-box ability to make use of the set of USB touchscreen devices supported by the composite USB driver. Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com --- meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc | 1 + meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc | 1 + meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc | 1 + meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc | 1 + meta/cfg/kernel-cache/bsp/fri2/fri2.scc | 1 + meta/cfg/kernel-cache/bsp/minnow/minnow.scc | 1 + meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc | 1 + 7 files changed, 7 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc index 68c1619..6151da1 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc +++ b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc @@ -5,6 +5,7 @@ include cfg/x86_64.scc include features/usb/ehci-hcd.scc include features/usb/uhci-hcd.scc include features/usb/ohci-hcd.scc +include features/usb/touchscreen-composite.scc include features/intel-e1/intel-e100.scc include features/intel-e1/intel-e1.scc include features/scsi/cdrom.scc diff --git a/meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc b/meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc index 3af9e88..1832ac8 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc +++ b/meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc @@ -5,5 +5,6 @@ include cfg/x86.scc include features/usb/ehci-hcd.scc include features/usb/uhci-hcd.scc include features/usb/ohci-hcd.scc +include features/usb/touchscreen-composite.scc include features/intel-e1/intel-e100.scc include features/intel-e1/intel-e1.scc diff --git a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc index 591ea1a..13794f7 100644 --- a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc +++ b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc @@ -10,3 +10,4 @@ include features/power/intel.scc include features/usb/ehci-hcd.scc include features/usb/ohci-hcd.scc +include features/usb/touchscreen-composite.scc diff --git a/meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc b/meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc index af2d708..4eed625 100644 --- a/meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc +++ b/meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc @@ -5,6 +5,7 @@ include cfg/8250.scc include features/usb/ehci-hcd.scc include features/usb/uhci-hcd.scc +include features/usb/touchscreen-composite.scc kconf hardware emenlow.cfg kconf non-hardware reboot-quirk.cfg diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc index fa718b1..8d4a656 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc @@ -8,4 +8,5 @@ include features/power/intel.scc include cfg/efi.scc include features/usb/ehci-hcd.scc include features/usb/ohci-hcd.scc +include features/usb/touchscreen-composite.scc include features/iwlwifi/iwlwifi.scc diff --git a/meta/cfg/kernel-cache/bsp/minnow/minnow.scc b/meta/cfg/kernel-cache/bsp/minnow/minnow.scc index 41b98a2..9d632df 100644 --- a/meta/cfg/kernel-cache/bsp/minnow/minnow.scc +++ b/meta/cfg/kernel-cache/bsp/minnow/minnow.scc @@ -6,6 +6,7 @@ include cfg/efi.scc include features/usb/ehci-hcd.scc include features/usb/ohci-hcd.scc include features/usb/usb-gadgets.scc +include features/usb/touchscreen-composite.scc include cfg/timer/hpet.scc include cfg/timer/rtc.scc include features/leds/leds.scc diff --git a/meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc b/meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc index fc1a9fe..b1f35a9 100644 --- a/meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc +++ b/meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc @@ -7,3 +7,4 @@ include cfg/8250.scc include cfg/usb-mass-storage.scc include features/power/intel.scc include cfg/efi.scc +include features/usb/touchscreen-composite.scc -- 1.7.11.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 0/3] Add support for USB touchscreens
This patchset adds support for USB touchscreens that can use the 'composite' touchscreen driver. Build-tested only (nuc and crownbay) since I don't have a USB touchscreen to test. Fixes Yocto Bug 4770 - Enable USB touchscreens The following changes since commit c0851dfb8535635e1e31d4a5146d3f021e30506c: meta/minnow: Add i2cdev support (2013-06-12 23:53:46 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib.git tzanussi/linux-yocto-3.8/touchscreen-features http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/linux-yocto-3.8/touchscreen-features Tom Zanussi (3): meta: add features/input/touchscreen meta: add usb/touchscreen-composite feature meta: add BSP-specific touchscreen support meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64.scc | 1 + meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc| 1 + meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc | 1 + meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc| 1 + meta/cfg/kernel-cache/bsp/fri2/fri2.scc | 1 + meta/cfg/kernel-cache/bsp/minnow/minnow.scc | 1 + meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc| 1 + meta/cfg/kernel-cache/features/input/touchscreen.cfg | 1 + meta/cfg/kernel-cache/features/input/touchscreen.scc | 4 meta/cfg/kernel-cache/features/usb/touchscreen-composite.cfg | 1 + meta/cfg/kernel-cache/features/usb/touchscreen-composite.scc | 7 +++ 11 files changed, 20 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/input/touchscreen.cfg create mode 100644 meta/cfg/kernel-cache/features/input/touchscreen.scc create mode 100644 meta/cfg/kernel-cache/features/usb/touchscreen-composite.cfg create mode 100644 meta/cfg/kernel-cache/features/usb/touchscreen-composite.scc -- 1.7.11.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
