[oe] oestats as automated testing reporting tool (Was: testing branch 2011-01-20)

[Tom Rini]

On 01/31/2011 02:22 AM, Yury Bushmelev wrote:
> 2011/1/29 Tom Rini<tom_rini at mentor.com>:
>> On 01/26/2011 03:04 PM, Yury Bushmelev wrote:
>>>
>>> I have spent some time to looking over oestats client and server code.
>>> Below are some ideas.
>>
>> [snip]
>>>>
>>>> - workstation (distro + arch)*
>>>
>>> We have build arch in oestats already (BUILD_ARCH). I'll prefer
>>> replace it with BUILD_SYS because we can use e.g.
>>> darwin/freebsd/cygwin as build host later.
>
>>> As there is no reliable way to get user's build host distro I'll ask
>>> to introduce new bitbake variable (OESTATS_HOST_DISTRO?).
>>
>> We can code some things up.  For example, if uname -o has Linux in the name,
>> we can see if lsb_release exists (more often than not, it will/should) and
>> then bam, we've got it.  Otherwise we can do some poking around before just
>> giving up.
>
> I'm considering using following scenario:
> a) try OESTATS_HOST_DISTRO in bb env
> a) try lsb_release -irc
> c) set it to "Please install lsb_release or setup OESTATS_HOST_DISTRO
> in your local.conf"
>
> We can get distro name by many other ways (/etc/issue,
> /etc/*-release). But I have no other reliable ideas how to get distro
> version.

Works for me.  Shouldn't spend too much time on the various corner cases 
here.

> I've found other problem. Kernel arch may be different from userspace
> arch. They may use i686 userspace with x86_64 kernel. I suspect that
> userspace arch is more interesting for us. First idea is using "file
> /sbin/init" e.g. to detect userspace arch and pass it as BUILD_ARCH.

Yeah, we really shouldn't care about the kernel arch, just the userspace 
arch.

-- 
Tom Rini
Mentor Graphics Corporation