[yocto] Where is the poky version information stored?
Hi, Is the poky version information stored in a particular file? I'd like to create a log tag in my git repo, and prefix it with the poky version. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documentation improvement
Jim, I am addressing issues in my email box (bottom up) and was not sure if I ever closed this one with you. I have made changes to the "Creating Configuration Fragments" section in the YP Development Manual "latest" version (http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#creating-config-fragments). I added wording from the BSP guide to help clear this up. If you want to examine the new section against the 1.2 version, see the same section in the current manual at http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-config-fragments. Thanks, Scott From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of jfabernathy Sent: Friday, July 06, 2012 11:59 AM To: yocto@yoctoproject.org Subject: [yocto] Documentation improvement I was looking at the Yocto Development Manual (Latest), section 4.6.2. Creating Config Fragments. I was confused about the file statement and the naming of the directory to locate the fragment file until I found a similar discussion in the BSP Guide (lastest) section 1.2.10. Linux Kernel Configuration. The section there is much more understandable. I think we need to modify the development manual or have it point to the BSP manual. The text from there (below) I think is better. I still think it's confusing about the naming of the subdirectory where the myconfig goes. Maybe a complete example would be good. For example, suppose you had a set of configuration options in a file called myconfig. If you put that file inside a directory named linux-yocto and then added a SRC_URI statement such as the following to the append file, those configuration options will be picked up and applied when the kernel is built. SRC_URI += "file://myconfig" As mentioned earlier, you can group related configurations into multiple files and name them all in the SRC_URI statement as well. For example, you could group separate configurations specifically for Ethernet and graphics into their own files and add those by using a SRC_URI statement like the following in your append file: SRC_URI += "file://myconfig \ file://eth.cfg \ file://gfx.cfg" ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where is the poky version information stored?
On Mon, Aug 27, 2012 at 8:36 AM, Elvis Dowson wrote: > Hi, >Is the poky version information stored in a particular file? I'd like > to create a log tag in my git repo, and prefix it with the poky version. > I guess DISTRO_VERSION is what you can use, which is defined in conf/distro/poky.conf but poky version and yocto version are two different things I dont know which one is more relevant > Best regards, > > Elvis Dowson > ___ > 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] 1.3 M3 Full Pass test results
Hi Laurentiu, Do you have any comment on the performance question Richard asked? I know your team is using a machine with different configuration from the one used by the Shanghai team. The performance figure from the Shanghai team has been hovering around 110 mins. That's the case for 1.2 release and 1.3 M2 milestone report. 1.3 M1 milestone report has the build time as 95 minutes, which I believe is from your team. So my question is whether you used the same machine for M3 performance testing as for M1. Another factor that might have caused the difference (between 95 and 83 minutes) is your testing procedure/environment such as other processes running at the same time, memory usage, sstate cache, etc. If you used the same machine and same testing procedure/environment, then we have some improvement in M3 compared with M1. Please let me know your thoughts. Thanks, Song -Original Message- From: Serban, Laurentiu Sent: Friday, August 24, 2012 6:34 AM To: Purdie, Richard Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: RE: 1.3 M3 Full Pass test results Hello Richard, Even if the installer is used in the default mode, issues still occur (see comment 7). I think the root cause for these is the same, so I did not submit a new bug. Thank you, Laurentiu -Original Message- From: Purdie, Richard Sent: Friday, August 24, 2012 1:22 PM To: Serban, Laurentiu Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: Re: 1.3 M3 Full Pass test results On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote: > Here are the results for the full pas tests on 1.3 M3 RC2. The commit > used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd. > > Some details about the encountered issues below: > > BSP – Sudoku-savant project build issue (2878) > > ADT – the relocatable sdk issue (2980) causes 13 test cases to be on > faile/blocked state I thought it worked as long as you didn't have to relocate it so no tests should have been blocked, we just have the relocation issue? > , also the Clutter C template issue is unsolved (2577) > > Core Build System – x32 is still an issue (2888), cleaning sstate > issue is still not solved (2897), incremental RPM image generation > (2969), source archiving (2619), the kvm issue was reproduced by > another colleague (2790) Yocto BSP creation via JSON (2693) or for > qemu (2991) fails, multilib issue (2918 – this requires a little more > investigation from QA), > > HOB - all seems ok for RC2 > > Self-hosted-image - cannot start on Virtual Box (X issue), it is very > slow on qemu and it has a m4 package build (3005) issue on VMWare. If > the self-hosted-image is used on machine with internet connectivity > via proxy there will be an initial sanity check failure, but this is > not a blocking issue. > > A mention for the performance testing: on a Ubbuntu 12.04 i7 machine > using 8 threads the build time was 83 minutes (with prior fetching). How does this compare with our other performance numbers. From what I remember, we used to hover around the 105-115 minute mark. Did we have some significant speed gains or is this just an artefact of changing the test machine? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3 M3 Full Pass test results
Hello guys, I am sorry I did not notice the last line in the e-mail. When we ran the performance testing we pre-downloaded all the sources, because last week had a lot of connectivity issues. I mentioned in the e-mail that the build time refers to an image built after all the sources were downloaded. The machine on which the test was ran is the same as for M1. I will ask Stefan to re-run the performance tests for the different milestones so far, M1 and M2, in the same conditions as for M3 so we would have a clear view. I add Jiajun in the loop so he can help us if he can with a test to see if this is related to an artifact as Richard said, but also there were some improvements made by Beth on filesystem generation. Br, Laurentiu -Original Message- From: Liu, Song Sent: Monday, August 27, 2012 8:50 PM To: Serban, Laurentiu; Purdie, Richard Cc: yocto@yoctoproject.org; Stewart, David C; Wold, Saul Subject: RE: 1.3 M3 Full Pass test results Hi Laurentiu, Do you have any comment on the performance question Richard asked? I know your team is using a machine with different configuration from the one used by the Shanghai team. The performance figure from the Shanghai team has been hovering around 110 mins. That's the case for 1.2 release and 1.3 M2 milestone report. 1.3 M1 milestone report has the build time as 95 minutes, which I believe is from your team. So my question is whether you used the same machine for M3 performance testing as for M1. Another factor that might have caused the difference (between 95 and 83 minutes) is your testing procedure/environment such as other processes running at the same time, memory usage, sstate cache, etc. If you used the same machine and same testing procedure/environment, then we have some improvement in M3 compared with M1. Please let me know your thoughts. Thanks, Song -Original Message- From: Serban, Laurentiu Sent: Friday, August 24, 2012 6:34 AM To: Purdie, Richard Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: RE: 1.3 M3 Full Pass test results Hello Richard, Even if the installer is used in the default mode, issues still occur (see comment 7). I think the root cause for these is the same, so I did not submit a new bug. Thank you, Laurentiu -Original Message- From: Purdie, Richard Sent: Friday, August 24, 2012 1:22 PM To: Serban, Laurentiu Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: Re: 1.3 M3 Full Pass test results On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote: > Here are the results for the full pas tests on 1.3 M3 RC2. The commit > used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd. > > Some details about the encountered issues below: > > BSP – Sudoku-savant project build issue (2878) > > ADT – the relocatable sdk issue (2980) causes 13 test cases to be on > faile/blocked state I thought it worked as long as you didn't have to relocate it so no tests should have been blocked, we just have the relocation issue? > , also the Clutter C template issue is unsolved (2577) > > Core Build System – x32 is still an issue (2888), cleaning sstate > issue is still not solved (2897), incremental RPM image generation > (2969), source archiving (2619), the kvm issue was reproduced by > another colleague (2790) Yocto BSP creation via JSON (2693) or for > qemu (2991) fails, multilib issue (2918 – this requires a little more > investigation from QA), > > HOB - all seems ok for RC2 > > Self-hosted-image - cannot start on Virtual Box (X issue), it is very > slow on qemu and it has a m4 package build (3005) issue on VMWare. If > the self-hosted-image is used on machine with internet connectivity > via proxy there will be an initial sanity check failure, but this is > not a blocking issue. > > A mention for the performance testing: on a Ubbuntu 12.04 i7 machine > using 8 threads the build time was 83 minutes (with prior fetching). How does this compare with our other performance numbers. From what I remember, we used to hover around the 105-115 minute mark. Did we have some significant speed gains or is this just an artefact of changing the test machine? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Request for photos
All - still would like to include as many pictures as I can of real products using the Yocto Project. Have not heard any... do you have a photo you can send me urgently? (Otherwise I will just make stuff up, and you don't want me to do that...) :-) Dave >-Original Message- >From: yocto-boun...@yoctoproject.org [mailto:yocto- >boun...@yoctoproject.org] On Behalf Of Stewart, David C >Sent: Tuesday, August 21, 2012 8:20 AM >To: yocto >Subject: [yocto] Request for photos > >All - I'm prepping to give a talk at LinuxCon next week on an update to the >Yocto Project, and I would like to create a slide which shows a bunch of >devices which are based on YP. > >Can you please send me a quick note with anything you know about to include >here? Particularly nice if you have a photo or logo for the thing. > >Thanks!! > >Dave ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, August 28, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Agenda: * Opens collection - 5 min (Song) * Yocto 1.3 M3 release readiness (All) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_3 https://wiki.yoctoproject.org/wiki/Yocto_1.3_Milestone_Test_Report (M3 report is at the bottom of the page) * Yocto 1.3 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status * SWAT team rotation: Ross -> LaurentiuP * Opens - 10 min * Team sharing - 20 min -Original Appointment- We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference details Conference name: Yocto Technical Team Conference date/start time: Tue Jun 26, 2012 at 10:00 AM Central Daylight Time Participants: 30 Duration: 60 minutes Participant passcode: 76994298 Dial-in number: 1.972.995. US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.x76994298# Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode. Local and Global Access Numbers Country Dial-in number Australia: 1800 636 843 Czech Republic: 242 430 350 China (Beijing): >From office dial 8-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): >From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): >From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): >From IP phone dial 8-995 Other cities - Non IP phone dial 021-23073322 Denmark: 8060 1400 Finland: 09 41333477 France: 0497 275888 Germany: 08161 803232 Holland: 030 2417490 India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 8995 Others use 2509 9555 (Landline within Bangalore) or 80 2509 9555 (Outside Bangalore) Israel: 09 790 6715 Italy: 039 69061234 (039 is local city code not country code) Japan: >From TI Campus use 8 995 Outside TI use 03 4331 3777 Malaysia: >From IP phone dial 2643799 >From Kuala Lumpur dial 4264 3799 Outside Kuala Lumpur dial (03)4264 3799 Norway: 2 295 8744 Philippines: >From Baguio City use 4471177 >From Metro Manila area use 8702477 Singapore: >From IP phone dial 3894777 Outside TI use 6389 4777 South Korea: >From IP phone dial 5606998 >From Seoul dial 5606998 Outside Seoul dial (02)5606998 Sweden: 08 58755577 Taiwan: >From IP phone dial 1363 >From Taipei dial 2241 1363 Outside Taipei dial (02)2241 1363 Turkey: Landline Only dial 0811 288 0001 then enter 877 633 1123 UK: 01604 663003 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 26, 2012 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends: End on Fri Jun 21, 2013, 10:40 AM CDT ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Xorg keyboard not working
I've got a system that has a working console and four virtual terminals. I can start X and run an application using /usr/bin/xinit /usr/sbin/xinitrc -- /usr/bin/Xorg The application runs fine and is expected to run with no user interaction. Keyboard input is sometimes needed to either kill the application or switch to another virtual terminal to make some configuration changes. However, I can't seem to get the keyboard to work - I can't switch virtual terminal or force the application to exit and the caps-lock light doesn't toggle. This is the same keyboard that was used to kick the application off. xf86-input-keyboard and xf86-input-evdev are both listed in 'XSERVER' when the system is baked. Where should I be looking to work out why the keyboard isn't working? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Poky 1.3_M3 branch does not work with linux-yocto 3.0 kernel ?
Hi, I am building a BSP (meta-cedartrail) using 1.3 M3 branch of Poky. When I try to boot a image such as core-image-sato, I get kernel panic and errors such as: VFS: Cannot open root device "ram0" or unkown-block(0,0) Please append a correct "root=" boot option; here are the available partitions: VFS: unable to mount root fs on unknown block(0,0) User configuration error - no valid rootfilesystem found I do see that the root file system exists in cedartrail-poky-linux/core-image-sato-1.0-r0/rootfs dir.. I did not see this problem when I uses a earlier commit of the Poky master branch. It seems like something broke with 1.3 M3 branch that prevents a proper build with 3.0 kernel. I do need to build my BSP with 3.0 kernel. (I was also told by Laurentiu Serban that 1.3 M3 Full Pass testing does not include testing with the 3.0 kernel) Any suggestions would be most welcome. I do need to build my BSP with the 3.0 kernel. Thanks Rahul ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3 M3 Full Pass test results
We used to get 115m and 127m for 1.3 M1 and M2 on our test machine. > Hello guys, > > I am sorry I did not notice the last line in the e-mail. > > When we ran the performance testing we pre-downloaded all the sources, > because last week had a lot of connectivity issues. I mentioned in the > e-mail that the build time refers to an image built after all the > sources were downloaded. > The machine on which the test was ran is the same as for M1. > > I will ask Stefan to re-run the performance tests for the different > milestones so far, M1 and M2, in the same conditions as for M3 so we > would have a clear view. > > I add Jiajun in the loop so he can help us if he can with a test to > see if this is related to an artifact as Richard said, but also there > were some improvements made by Beth on filesystem generation. > > Br, > Laurentiu > > -Original Message- > From: Liu, Song > Sent: Monday, August 27, 2012 8:50 PM > To: Serban, Laurentiu; Purdie, Richard > Cc: yocto@yoctoproject.org; Stewart, David C; Wold, Saul > Subject: RE: 1.3 M3 Full Pass test results > > Hi Laurentiu, > > Do you have any comment on the performance question Richard asked? I > know your team is using a machine with different configuration from > the one used by the Shanghai team. The performance figure from the > Shanghai team has been hovering around 110 mins. That's the case for > 1.2 release and 1.3 M2 milestone report. 1.3 M1 milestone report has > the build time as 95 minutes, which I believe is from your team. So my > question is whether you used the same machine for M3 performance > testing as for M1. Another factor that might have caused the > difference (between 95 and 83 minutes) is your testing > procedure/environment such as other processes running at the same > time, memory usage, sstate cache, etc. If you used the same machine > and same testing procedure/environment, then we have some improvement in M3 > compared with M1. Please let me know your thoughts. > > Thanks, > Song > > -Original Message- > From: Serban, Laurentiu > Sent: Friday, August 24, 2012 6:34 AM > To: Purdie, Richard > Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul > Subject: RE: 1.3 M3 Full Pass test results > > Hello Richard, > > Even if the installer is used in the default mode, issues still occur > (see comment 7). I think the root cause for these is the same, so I did not > submit a new bug. > > Thank you, > Laurentiu > > -Original Message- > From: Purdie, Richard > Sent: Friday, August 24, 2012 1:22 PM > To: Serban, Laurentiu > Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul > Subject: Re: 1.3 M3 Full Pass test results > > On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote: > >> Here are the results for the full pas tests on 1.3 M3 RC2. The >> commit used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd. >> >> Some details about the encountered issues below: >> >> BSP – Sudoku-savant project build issue (2878) >> >> ADT – the relocatable sdk issue (2980) causes 13 test cases to be on >> faile/blocked state > > I thought it worked as long as you didn't have to relocate it so no > tests should have been blocked, we just have the relocation issue? > >> , also the Clutter C template issue is unsolved (2577) >> Core Build System – x32 is still an issue (2888), cleaning sstate >> issue is still not solved (2897), incremental RPM image generation >> (2969), source archiving (2619), the kvm issue was reproduced by >> another colleague (2790) Yocto BSP creation via JSON (2693) or for >> qemu (2991) fails, multilib issue (2918 – this requires a little >> more investigation from QA), >> >> HOB - all seems ok for RC2 >> >> Self-hosted-image - cannot start on Virtual Box (X issue), it is >> very slow on qemu and it has a m4 package build (3005) issue on >> VMWare. If the self-hosted-image is used on machine with internet >> connectivity via proxy there will be an initial sanity check >> failure, but this is not a blocking issue. >> >> A mention for the performance testing: on a Ubbuntu 12.04 i7 >> machine using 8 threads the build time was 83 minutes (with prior fetching). > > How does this compare with our other performance numbers. From what I > remember, we used to hover around the 105-115 minute mark. Did we have > some significant speed gains or is this just an artefact of changing > the test machine? > > Cheers, > > Richard > > Best Regards, Jiajun ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky 1.3_M3 branch does not work with linux-yocto 3.0 kernel ?
On 12-08-27 8:14 PM, Saxena, Rahul wrote: Hi, I am building a BSP (meta-cedartrail) using 1.3 M3 branch of Poky. When I try to boot a image such as core-image-sato, I get kernel panic and errors such as: VFS: Cannot open root device “ram0” or unkown-block(0,0) Please append a correct “root=” boot option; here are the available partitions: VFS: unable to mount root fs on unknown block(0,0) User configuration error – no valid rootfilesystem found I do see that the root file system exists in cedartrail-poky-linux/core-image-sato-1.0-r0/rootfs dir.. I did not see this problem when I uses a earlier commit of the Poky master branch. It seems like something broke with 1.3 M3 branch that prevents a proper build with 3.0 kernel. I do need to build my BSP with 3.0 kernel. (I was also told by Laurentiu Serban that 1.3 M3 Full Pass testing does not include testing with the 3.0 kernel) Any suggestions would be most welcome. I do need to build my BSP with the 3.0 kernel. Hmm. It should work, I booted one not that long ago. Can you force qemux86 to prefer the 3.0 kernel and see if that boots ? That would at least start to isolate the potential problem areas. Bruce Thanks Rahul ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
