[yocto] Fwd: build failure on ubuntu 64bits development system

[James Abernathy]

---------- Forwarded message ----------
From: William Mills <wmills at ti.com>
Date: Wed, Jan 18, 2012 at 9:57 AM
Subject: Re: [yocto] build failure on ubuntu 64bits development system
To: Gary Thomas <gary at mlbassoc.com>
Cc: yocto at yoctoproject.org




On 01/18/2012 09:51 AM, Gary Thomas wrote:

> On 2012-01-18 07:42, James Abernathy wrote:
>
>>
>>
>> On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy <jfabernathy at gmail.com<mailto:
>> jfabernathy at gmail.com>**> wrote:
>>
>>
>>
>>    On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy <
>> jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>**> wrote:
>>
>>        I just built a new development pc and installed Ubuntu 11.10 x64.
>>  I wonder if there are any new requirements to building Yocto in that
>> environment?  I got an error right
>>        off, but then it complete the first 63 task and stopped
>> successfully.  error below:
>>
>>        jim at ubuntu:~/poky/build-cdv$ bitbake core-image-sato
>>        Pseudo is not present but is required, building this first before
>> the main build
>>        Parsing recipes: 100% |#############################**####################|
>> Time: 00:00:25
>>        Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037
>> targets, 22 skipped, 0 masked, 0 errors.
>>        ERROR: Execution of event handler 'run_buildstats' failed
>>        Traceback (most recent call last):
>>           File "run_buildstats(e)", line 18, in
>> run_buildstats(e=<bb.event.**BuildStarted object at 0x4c338d0>)
>>           File "buildstats.bbclass", line 21, in set_device(e=<bb.event.*
>> *BuildStarted object at 0x4c338d0>)
>>        UnboundLocalError: local variable 'rdev' referenced before
>> assignment
>>
>>
>>        Any ideas?
>>
>>        JIm A
>>
>>
>>    I went back and tried using the tarballs for poky edison and
>> cedartrail bsp and the errors don't occur.  So I'm guessing the issue isn't
>> related to Ubuntu 32 vs. 64 bit.
>>
>>
>> I spoke too soon. Same error in edison tarballs.  I looked at the code
>> and I can see an place were rdev could go un assigned. If you fell out of
>> the for loop without passing any of
>> the if conditions, rdev would be unassigned.  That must be what is
>> happening in Ubuntu 11.10 x64
>>
>> Anybody building with Ubuntu 11.10 x64?  This doesn't happen on x32
>>
>> Jim A
>>
>>
>> def set_device(e):
>>     tmpdir = bb.data.getVar('TMPDIR', e.data, True)
>>     try:
>>         os.remove(bb.data.getVar('**DEVFILE', e.data, True))
>>     except:
>>         pass
>>     ##############################**##############################**
>> ################
>>     # We look for the volume TMPDIR lives on. To do all disks would make
>> little
>>     # sense and not give us any particularly useful data. In theory we
>> could do
>>     # something like stick DL_DIR on a different partition and this would
>>     # throw stats gathering off. The same goes with SSTATE_DIR. However,
>> let's
>>     # get the basics in here and work on the cornercases later.
>>     ##############################**##############################**
>> ################
>>     device=os.stat(tmpdir)
>>     majordev=os.major(device.st_**dev)
>>     minordev=os.minor(device.st_**dev)
>>     for line in open("/proc/diskstats", "r"):
>>         if majordev == int(line.split()[0]) and minordev ==
>> int(line.split()[1]):
>>            rdev=line.split()[2]
>>     file = open(bb.data.getVar('DEVFILE', e.data, True), "w")
>>     file.write(rdev)
>>     file.close()
>>
>
> Can you show what the differences are between /proc/diskstats
> on the two systems?  That's obviously what's causing the error.
>
>
If your build dir is encyptfs or a fuse device or anything that is not a
direct block device you will get this error.  This is to be fixed in 1.1.1
but encyptfs will still have other problems.

I build the Ubuntu 11.10 x64 system with 2 drives setup as Soft RAID 0. I
picked btrfs as the file system for no particular reason.  Should I go back
to ext4 or is RAID 0 the problem?

JIm A

______________________________**_________________
yocto mailing list
yocto at yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20120118/e153c1bf/attachment.html>