Hi, Dave, Yes, LSB contains cron. I talked to Jiajun about choice of the profile. SDK profile simplifies QA's test effort since it runs on both Qemu and real hardware, while LSB profile is not suitable for most real hardware. Also LSB profile lacks of some toolchain and development packages which is not good for openposix test. That's why SDK profile is used now though LSB contains more complete packages.
There're several cron related failures. One of them also exists on native, with the rest specific to Yocto. On LSB profile I expect cron should work, however it looks like some files are missing. I'm still looking into them. You can see from the table that I firstly focus on two categories: a) Failures also existing on native (so-called 'LTP') b) Failures disappearing with LSB profile (so-called 'NAB': Not-A-Bug) For the rest failures which fail both on SDK and LSB profile, I'll fill bugzilla after some preliminary analysis to make sure it's a real problem instead of the environmental issue. Now I haven't fill any bug for them yet. Thanks Kevin From: Stewart, David C Sent: Thursday, January 13, 2011 12:38 AM To: Tian, Kevin; yocto@yoctoproject.org; p...@pokylinux.org Subject: RE: LTP status for Yocto 1.0/M2 Kevin - this is quite valuable analysis into the test failures - thank you! The one which surprises me is the cron failure. But sure enough, the Sato image I have running on my desk doesn't have cron anything installed. So I'm wondering, which build profile do we test against? LSB? Also, do we have bugzillas for the failures? Dave From: poky-boun...@yoctoproject.org [mailto:poky-boun...@yoctoproject.org] On Behalf Of Tian, Kevin Sent: Wednesday, January 12, 2011 3:24 AM To: yocto@yoctoproject.org; p...@pokylinux.org Subject: [poky] LTP status for Yocto 1.0/M2 Hi, all, I'd like to give a quick update about current LTP status. For detail, please check out: https://wiki.yoctoproject.org/wiki/LTP_result Generally LTP is for desktop compliance and not strictly apply to Yocto when customized for specific purpose. So the main purpose of this task is: a) Track ongoing trend to avoid regression b) Understand existing failures and category whether they simply come from customization The stretch goal is: c) Reduce the failures as much as possible Now I'd like to say that: a) is done by abstracting data from our QA results b) is largely done and most failures falling into that category have been recorded c) is on-going the summary as below: The majority of the failures are common to all the targets, and thus I now focus on qemux86 for major analysis. The "similarity" row above shows how much common failures exist on other targets compared to qemux86. Because current round of QA test uses a "quiet" option when doing LTP test, lots of debug information are lost. So the similarity is simply done by compare the name of the failed cases, instead of checking its actual error output. I'll confirm them later manually, but current ratio still makes lots of sense. Beagleboard and routerstation may require recollecting data. On beagleboard, the low similarity is caused by missing an option when doing LTP test. On routerstation, it looks that kernel config options for IPC (sem, shm, msq, ...) are problematic and the disk space is also not enough. You can click the target name like "qemux86" to get detail progress for each target. For example, for qemux86: https://wiki.yoctoproject.org/wiki/Qemux86-ltp For other targets, there's a similarity line to show the difference with qemux86. Take qemux86-64 for example: https://wiki.yoctoproject.org/wiki/Qemux86_64-ltp Let me know if you have any comments. Thanks Kevin
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
