Forums

1. I run into this error today...and I do not understand because two days ago all went fine...
For the second attemp I did a dry run and I got the same error.

What can I do to solve this?

2. I use Ubuntu 11.04 with python-psyco installed and still I get the warning NOT Available...
Is there some setting one must perform, so psyco is used?

dgroov@dgroov-MS-7021:~/openpli/build-vuuno$  bitbake -n /home/dgroov/openpli/openembedded/recipes/linux/linux-vuuno_2.6.18.bb
NOTE: Psyco JIT Compiler (http://psyco.sf.net) not available. Install it to increase performance.
Loading cache: 100% |################################################################| ETA:  00:00:00
Loaded 7345 entries from dependency cache.
Parsing recipes: 100% |##############################################################| Time: 00:02:39
Parsing of 7545 .bb files complete (6719 cached, 826 parsed). 8191 targets, 357 skipped, 2 masked, 0 errors.
WARNING: No bb files matched BBFILE_PATTERN_overlay '/home/dgroov/openpli/local'


Build Configuration:
BB_VERSION	   = "1.12.0"
METADATA_BRANCH   = "2.1"
METADATA_REVISION = "b914858"
TARGET_ARCH	  = "mipsel"
TARGET_OS	    = "linux"
MACHINE		 = "vuuno"
DISTRO		  = "openpli"
DISTRO_VERSION    = "2.1"

ERROR: Nothing PROVIDES '/home/dgroov/openpli/openembedded/recipes/linux/linux-vuuno_2.6.18.bb'
ERROR: Command execution failed: Traceback (most recent call last):
  File "/home/dgroov/openpli/bitbake/lib/bb/command.py", line 102, in runAsyncCommand
    commandmethod(self.cmds_async, self, options)
  File "/home/dgroov/openpli/bitbake/lib/bb/command.py", line 200, in buildTargets
    command.cooker.buildTargets(pkgs_to_build, task)
  File "/home/dgroov/openpli/bitbake/lib/bb/cooker.py", line 751, in buildTargets
    taskdata.add_provider(localdata, self.status, k)
  File "/home/dgroov/openpli/bitbake/lib/bb/taskdata.py", line 353, in add_provider
    self.add_provider_internal(cfgData, dataCache, item)
  File "/home/dgroov/openpli/bitbake/lib/bb/taskdata.py", line 373, in add_provider_internal
    raise bb.providers.NoProvider(item)
NoProvider: /home/dgroov/openpli/openembedded/recipes/linux/linux-vuuno_2.6.18.bb

dgroov@dgroov-MS-7021:~/openpli/build-vuuno$

I can't check what the option -n does right now, but I usually use -b to build a bb directly.

-n, --dry-run don't execute, just go through the motions

With -b one will get the same error..

dgroov@dgroov-MS-7021:~$ bitbake -b /home/dgroov/openpli/openembedded/recipes/linux/linux-vuuno_2.6.18.bb 
ERROR: Command execution failed: Traceback (most recent call last):
  File "/home/dgroov/openpli/bitbake/lib/bb/command.py", line 102, in runAsyncCommand
    commandmethod(self.cmds_async, self, options)
  File "/home/dgroov/openpli/bitbake/lib/bb/command.py", line 190, in buildFile
    command.cooker.buildFile(bfile, task)
  File "/home/dgroov/openpli/bitbake/lib/bb/cooker.py", line 627, in buildFile
    buildfile = self.matchFile(fn)
  File "/home/dgroov/openpli/bitbake/lib/bb/cooker.py", line 604, in matchFile
    matches = self.matchFiles(buildfile)
  File "/home/dgroov/openpli/bitbake/lib/bb/cooker.py", line 586, in matchFiles
    filelist, masked = self.collect_bbfiles()
  File "/home/dgroov/openpli/bitbake/lib/bb/cooker.py", line 853, in collect_bbfiles
    files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) )
  File "/home/dgroov/openpli/bitbake/lib/bb/cooker.py", line 853, in <lambda>
    files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) )
  File "/home/dgroov/openpli/bitbake/lib/bb/cooker.py", line 397, in calc_bbfile_priority
    for _, _, regex, pri in self.status.bbfile_config_priorities:
AttributeError: 'NoneType' object has no attribute 'bbfile_config_priorities'

dgroov@dgroov-MS-7021:~$

That doesn't seem like the same problem .
Anyway we are experiencing the same problems during the build.

Indeed it is not the same error output...but I meant that execution failed..

I had the same issue Friday during the day and the build from FridayNight/Saterday went fine.

I assume the linux-vuuno_2.6.18.bb is still the same.

dont run your own build VU+ Uno images yet
your remote will not be recognized!

therefor we didnt integrate it yet to our buildenvironment
just wait until we have a working setup

Or help us solve the remote problem .

dont run your own build VU+ Uno images yet
your remote will not be recognized!

therefor we didnt integrate it yet to our buildenvironment
just wait until we have a working setup

What do you mean....?

I am already running this on my UNO with the image baked saterday and Ihad no RC problems with the remote.

I use the latetest drivers for the UNO so I can use the UNO remote without interfering with my duo.

Uno has an new universal RC wich is programmable to use for UNO or Duo...

Already programmed my harmony to switch RC for Uno/duo

other team developers reported serious problems
after flashing they couldnt use the RC anymore

we are investigating this

Or help us solve the remote problem .

I have the impression you don't have or using the latetst universal UNO RC,

In that case you can also try to use an harmony in the meantime.

It is already in the database of harmony..

other team developers reported serious problems
after flashing they couldnt use the RC anymore

we are investigating this

I can only tell you that I am using the UNO for some time now and tested
with original, VTI, VIX and BlackHole with cec support and I had no serioeus problems with the remote after flashing.


I find it very strange.....but again which RC do you use. The old one or the latest?

i dont have an uno to test

But I have one and can test...... and PLi is running very nice at the moment as we speak./images/smiley/grin.gif

With the latest drivers vuplus made seperate ir codes for duo and Uno, so one can use the new RC without interfering other vu boxes.

But here really no serious troubles after flashing. My remote always respond after testing a lot with different images.

So if you want me to test....I will be glad to do so for Pli team.

other team developers reported serious problems
after flashing they couldnt use the RC anymore
we are investigating this

There is not really a problem.

The situation is as follows:
The UNO is delivered with a universal remote (made by Philips). In this case "universal" means not only that TV- & Volume settings can be "punched" to the TV/Amplifier, but also that the remote can be set to command either the DUO/Solo (mode setting 1) or the UNO (mode setting 2) (and even the Ultimo using mode setting 3). Until recently the DUO, Solo & UNO "listened" to all modes.
However: since the latest drivers (dated 17/8) the UNO only "listens" to the universal R/C set to mode 2 (as it is by default, because it is delivered with the UNO). And the DUO/Solo only listen to their own R/C.
So: if you are using the R/C that belongs to the box there is no problem at all.

For several teams there is however a problem: the pre-production UNO's were delivered with a DUO R/C (because the universal R/C's were not available yet). So only those who don't have a universal R/C can run into problems. This is easy to overcome if you are using a Logitech Harmony, as in their database Logitech already has the correct commands.

i dont know which receiver-type and RC-type the other developer has
i only know that he couldnt use the box with the/a remote


PS. we dont use Logitech devices to test our hardware

Okay, but now PLi knows the RC isn't a problem and it actually never was.
Even in the past with the old duo RC I used...gave me no problems after flashing.

Only with the latest drivers one needs the new universal RC and this is working fine.
So perhaps this got mixed up by the developer for some reason.

I don't know which receiver-type and RC-type the other developer has, I only know that he couldn't use the box with the/a remote

Well, now we know........

PS: We don't use Logitech devices to test our hardware

That's a pity: you don't know what you are missing. And I presume you're testing software, not hardware?

Tried it here...

The factory firmware in the VU+uno responded to the (white) VU+duo remote.

After flashing a daily build, the box responds to neither the white VU+duo RC nor the black remote that was delivered along with it.

Apart from the color, the remotes look exactly alike.

After flashing a daily build, the box responds to neither the white VU+duo RC nor the black remote that was delivered along with it.

So that's either a DUO R/C (those were delivered with the pre-production UNO's; and doesn't have the TV-button on the top-left) or the R/C was set to mode 1.

The latter can easily be changed. The manual tells you how, if you don't have the manual I can tell you.

Then my error with compiling leads to clarifying that there is nothing wrong with the RC/images/smiley/grin.gif and can besolved easily.

6. System Code Change.
You can change the system code of your Vu+ universal RCU according to the Vu+ model that you want to
control. The default system code is Mode 2.
Mode 1 : SOLO / DUO
Mode 2 : UNO
Mode 3 & 4 : reserved for future models.
Press <<2 + 7>>, <HELP>, <0001 or 0002 or 0003 or 0004>
1. Press 2 and 7 for three seconds until LED is on.
2. Press HELP
3. Press <0001 or 0002 or 0003 or 0004>

@Milo....you have made a daily build today? but i get this starnge error suddenly.

Do you have an idea why i get this error?