some more non fetching recipes

some more non fetching recipes

[Frans Meulenbroeks]

Apart from the opensync and uclibc recipes that did not fetch and were
reported before, I did get fetch issues for the files below.
Haven't had time to dig into these, so some of these might be false alarms.
If anyone feels attached to a recipe or can say something about it,
please take action.

Frans.

PS: I removed the ti folder in this test; that one has recipes for
which the SRC_URI seems to depend upon an external var (or vars) or
which needed to be downloaded manually

binutils/mingw-binutils-canadian-cross_2.20.bb
binutils/mingw-binutils_2.20.bb
bluez/bluez-gnome_cvs.bb
cacao/cacao-native_hg.bb
cumulus/cumulus_cvs.bb
dpkg/dpkg-native_1.14.29.bb
dpkg/dpkg_1.14.29.bb
gpe-edit/gpe-edit_svn.bb
gpsdrive/gpsdrive-pda_2.10pre2.bb
gstreamer/gst-plugins-ugly-sid_0.10.7.bb
hal/hal_git.bb
kismet/kismet-newcore_svn.bb
kismet/kismet_svn.bb
konqueror/konqueror-embedded_20060404.bb
linux-uml/linux-uml_2.4.26.bb
linux-uml/linux-uml_2.6.11-rc2-mm1.bb
maemo/nokia770-init_1.0.bb
mamona/cx3110x-770he_0.8.1.bb
mamona/cx3110x-chinooke_2.0.15.bb
mamona/cx3110x-diablo_2.0.15.bb
mamona/uinput_2.6.21.bb
matchbox-panel/matchbox-panel_svn.bb
mplayer/mplayer-maemo_svn.bb
musicpd/gmpc_svn.bb
networkmanager/networkmanager_svn.bb
openmoko-projects/paroli_git.bb
openmoko-projects/tichy_git.bb
openmoko2/openmoko-alsa-scenarios_svn.bb
openmoko2/openmoko-contacts2_svn.bb
openmoko2/openmoko-dates2_svn.bb
openmoko2/openmoko-tasks2_svn.bb
pidgin/msn-pecan_git.bb
pimlico/contacts_svn.bb
pimlico/dates_svn.bb
pimlico/tasks_svn.bb
powervr-drivers/bc-cube_0.1.0.bb
powervr-drivers/bc-cube_0.2.0.bb
powervr-drivers/libgles-omap3_3.01.00.02.bb
powervr-drivers/libgles-omap3_3.01.00.06.bb
powervr-drivers/libgles-omap3_3.01.00.07.bb
powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
python/python-psyco_1.6.bb
qt4/qt4-embedded-gles_4.6.0.bb
qt4/qt4-embedded-gles_4.6.2.bb
qt4/qt4-embedded-gles_4.6.3.bb
qt4/qt4-x11-free-gles_4.5.2.bb
qt4/qt4-x11-free-gles_4.6.0.bb
qt4/qt4-x11-free-gles_4.6.2.bb
qt4/qt4-x11-free-gles_4.6.3.bb
qt4/qt4-x11-free-gles_4.7.0.bb
rp-pppoe/rp-pppoe_3.5.bb
schroedinger/gst-plugin-schroedinger_1.0.9.bb
tinymail/libtinymail_svn.bb
tinymail/tmut_svn.bb
tinymail/libtinymail_svn.bb
tinymail/tmut_svn.bb
u-boot/u-boot-bug_svn.bb
u-boot/u-boot-omap3beagleboard_1.1.4.bb
u-boot/u-boot-omap3pandora_git.bb
u-boot/u-boot_git.bb
xffm/xffm_4.3.99.2.bb
xorg-driver/xf86-input-vmmouse_12.6.10.bb
xorg-driver/xf86-input-vmmouse_12.6.5.bb
xorg-driver/xf86-video-geode_2.11.6.bb
xorg-driver/xf86-video-geode_2.11.9.b

Re: some more non fetching recipes

[Holger Freyther]

On 09/26/2010 06:21 PM, Frans Meulenbroeks wrote:

> dpkg/dpkg-native_1.14.29.bb
> dpkg/dpkg_1.14.29.bb

fetct the rev from archive, or better upgrade..




> openmoko-projects/paroli_git.bb
> openmoko-projects/tichy_git.bb
> openmoko2/openmoko-alsa-scenarios_svn.bb
> openmoko2/openmoko-contacts2_svn.bb
> openmoko2/openmoko-dates2_svn.bb
> openmoko2/openmoko-tasks2_svn.bb

oh, the servers should still be running.



> powervr-drivers/bc-cube_0.1.0.bb
> powervr-drivers/bc-cube_0.2.0.bb
> powervr-drivers/libgles-omap3_3.01.00.02.bb
> powervr-drivers/libgles-omap3_3.01.00.06.bb
> powervr-drivers/libgles-omap3_3.01.00.07.bb
> powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> qt4/qt4-embedded-gles_4.6.0.bb
> qt4/qt4-embedded-gles_4.6.2.bb
> qt4/qt4-embedded-gles_4.6.3.bb
> qt4/qt4-x11-free-gles_4.5.2.bb
> qt4/qt4-x11-free-gles_4.6.0.bb
> qt4/qt4-x11-free-gles_4.6.2.bb
> qt4/qt4-x11-free-gles_4.6.3.bb
> qt4/qt4-x11-free-gles_4.7.0.bb

I assume these require the powervr manual download?

Re: some more non fetching recipes

[Martin Jansa]

On Sun, Sep 26, 2010 at 12:21:36PM +0200, Frans Meulenbroeks wrote:
> Apart from the opensync and uclibc recipes that did not fetch and were
> reported before, I did get fetch issues for the files below.
> Haven't had time to dig into these, so some of these might be false alarms.
> If anyone feels attached to a recipe or can say something about it,
> please take action.

There was about ~1000 recipes failing to fetch few months ago, I don't
think this number is that much lower as I haven't seen any changes in
most of them.

See my download status:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019206.html
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019234.html

but I was testing not only latest version, but all versions and for all
ARCHs.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: some more non fetching recipes

[Frans Meulenbroeks]

2010/9/26 Holger Freyther <holger+oe@freyther.de>:
> On 09/26/2010 06:21 PM, Frans Meulenbroeks wrote:
>
>> dpkg/dpkg-native_1.14.29.bb
>> dpkg/dpkg_1.14.29.bb
>
> fetct the rev from archive, or better upgrade..

if it is available somewhre else I can fetch from elsewhere,
upgrade is too much work for a recipe that I do not use and have no
idea on how to test
>
>
>
>
>> openmoko-projects/paroli_git.bb
>> openmoko-projects/tichy_git.bb
>> openmoko2/openmoko-alsa-scenarios_svn.bb
>> openmoko2/openmoko-contacts2_svn.bb
>> openmoko2/openmoko-dates2_svn.bb
>> openmoko2/openmoko-tasks2_svn.bb
>
> oh, the servers should still be running.

What do you mean to say with that?
>
>
>
>> powervr-drivers/bc-cube_0.1.0.bb
>> powervr-drivers/bc-cube_0.2.0.bb
>> powervr-drivers/libgles-omap3_3.01.00.02.bb
>> powervr-drivers/libgles-omap3_3.01.00.06.bb
>> powervr-drivers/libgles-omap3_3.01.00.07.bb
>> powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
>> powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
>> qt4/qt4-embedded-gles_4.6.0.bb
>> qt4/qt4-embedded-gles_4.6.2.bb
>> qt4/qt4-embedded-gles_4.6.3.bb
>> qt4/qt4-x11-free-gles_4.5.2.bb
>> qt4/qt4-x11-free-gles_4.6.0.bb
>> qt4/qt4-x11-free-gles_4.6.2.bb
>> qt4/qt4-x11-free-gles_4.6.3.bb
>> qt4/qt4-x11-free-gles_4.7.0.bb
>
> I assume these require the powervr manual download?

The first ones maybe, the qt ones seem to refer to files that are not
on the trolltech site any more. Then again the non-gles version
fetches.
I've just give it a short try and I guess this is recipe or bitbake related:

frans@linux-suse:~/oe/openembedded/recipes/qt4> bitbake -cclean -b
qt4-x11-free-gles_4.6.3.bb
ERROR: Command execution failed: Traceback (most recent call last):
  File "/home/frans/oe/bitbake/lib/bb/command.py", line 88, in runAsyncCommand
    commandmethod(self.cmds_async, self, options)
  File "/home/frans/oe/bitbake/lib/bb/command.py", line 174, in buildFile
    command.cooker.buildFile(bfile, task)
  File "/home/frans/oe/bitbake/lib/bb/cooker.py", line 650, in buildFile
    self.status.task_deps[fn]['depends'] = {}
TypeError: 'NoneType' object does not support item assignment

Frans

>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: some more non fetching recipes

[Frans Meulenbroeks]

2010/9/26 Martin Jansa <martin.jansa@gmail.com>:
> On Sun, Sep 26, 2010 at 12:21:36PM +0200, Frans Meulenbroeks wrote:
>> Apart from the opensync and uclibc recipes that did not fetch and were
>> reported before, I did get fetch issues for the files below.
>> Haven't had time to dig into these, so some of these might be false alarms.
>> If anyone feels attached to a recipe or can say something about it,
>> please take action.
>
> There was about ~1000 recipes failing to fetch few months ago, I don't
> think this number is that much lower as I haven't seen any changes in
> most of them.
>
> See my download status:
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019206.html
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019234.html
>
> but I was testing not only latest version, but all versions and for all
> ARCHs.

I think we got rid of some of these as some of the recipes have been
moved to non-working, but it could well be the there are still 900 or
so non-fetchers.
(note that I didn't do a full test, I only peeked at recipes that also
contained unused patch files; since I wanted to verify those).

But you've hit an intrinsic problem in OE:
there is a lot of crud/non-working recipes around and if you report it
there are three possible scenarios:
- someone tells you "go fix it"
- nothing happens ( the most likely scenario)
- someone actually takes action (very rare)

And if you go ahead and fix things people will axe you if you make a mistake.
Caused by the latter I have decided for now (maybe to the relief of
some) to only fix recipes that I am really interested in, and for the
rest restrict myself to reporting the issue.
The negative vibes that my attempt to do some generic cleanup caused,
resulted in the conclusion that it is not worthwhile my time and
energy. Sad but true.

What OE really need is a sense of recipe/machine/distro ownership and
a set of QA guidelines for recipes.
My guesstimate is that currently almost half of the recipes are
non-working/obsoleted by newer versions/outdated/non-maintained.

Frans.

PS: I will still work on removing the unused patches. I feel obliged
to fix that as some of it may be relics from my recipe removal in aug.
Anyway that work is fairly well automated by now and requires little
handwork (assuming recipes fetch, so cleaning dirs with non-fetching
recipes might be skipped).

Re: some more non fetching recipes

[Frans Meulenbroeks]

2010/9/26 Martin Jansa <martin.jansa@gmail.com>:

> There was about ~1000 recipes failing to fetch few months ago, I don't
> think this number is that much lower as I haven't seen any changes in
> most of them.
>
> See my download status:
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019206.html
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019234.html

April is 5 months ago. Question is if it makes sense to keep recipes
that are broken for > 5 months and no one who saw a need to fix them
or complained about them.
Personally I'm inclined to say it is a waste to spend any time on
these. I would suggest moving them to e.g. nonworking but I guess the
people who mix up quality and quantity will disagree on this.

Frans.

Re: some more non fetching recipes

[Mike Westerhof]

On 9/27/2010 1:19 AM, Frans Meulenbroeks wrote:
> 2010/9/26 Martin Jansa <martin.jansa@gmail.com>:
> 
>> There was about ~1000 recipes failing to fetch few months ago, I don't
>> think this number is that much lower as I haven't seen any changes in
>> most of them.
>>
>> See my download status:
>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019206.html
>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019234.html
> 
> April is 5 months ago. Question is if it makes sense to keep recipes
> that are broken for > 5 months and no one who saw a need to fix them
> or complained about them.
> Personally I'm inclined to say it is a waste to spend any time on
> these. I would suggest moving them to e.g. nonworking but I guess the
> people who mix up quality and quantity will disagree on this.

Mix up quality and quantity?  That's a gross mischaracterization on your
part, and I quite resent it.

There are valid reasons for some of those.  If it is now necessary to
make Mr. Jansa like the comments on the ixp4xx firmware recipe in order
to keep the recipe in OE, I will update those.  But I cannot make it so
that Intel will not require click-throughs in order to download the
firmware files.

-Mike (mwester)

Re: some more non fetching recipes

[Frans Meulenbroeks]

2010/9/27 Mike Westerhof <mike@mwester.net>:
> On 9/27/2010 1:19 AM, Frans Meulenbroeks wrote:
>> 2010/9/26 Martin Jansa <martin.jansa@gmail.com>:
>>
>>> There was about ~1000 recipes failing to fetch few months ago, I don't
>>> think this number is that much lower as I haven't seen any changes in
>>> most of them.
>>>
>>> See my download status:
>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019206.html
>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-April/019234.html
>>
>> April is 5 months ago. Question is if it makes sense to keep recipes
>> that are broken for > 5 months and no one who saw a need to fix them
>> or complained about them.
>> Personally I'm inclined to say it is a waste to spend any time on
>> these. I would suggest moving them to e.g. nonworking but I guess the
>> people who mix up quality and quantity will disagree on this.
>
> Mix up quality and quantity?  That's a gross mischaracterization on your
> part, and I quite resent it.
>
> There are valid reasons for some of those.  If it is now necessary to
> make Mr. Jansa like the comments on the ixp4xx firmware recipe in order
> to keep the recipe in OE, I will update those.  But I cannot make it so
> that Intel will not require click-throughs in order to download the
> firmware files.
>
> -Mike (mwester)

To clarify:
Things that do not fetch because they require a manual download with
accepting a license etc, I do not consider as broken.
And of course we should keep these (I know the ixp4xx situation quite well).
But how many of those do we have? I know about the ixp4xx and some ti
ones. Maybe there are a few more that I missed but then again, most of
the ~1000 recipes Martin mentioned and a lot of the recipes I listed
above do not fall into this category but refer e.g. to a cvs server
that is not there any more, to a version, tag or tarball that does not
exist etc etc.

For me those recipes are broken. And if it is a recipe that is broken
for a prolonged amount of time, there is apparently no interest in it,
and personally I would like to have this indicated one way or another,
or, even better, move these recipes into a dedicated folder(like
nonworking). In that case the recipe is still there should somebody be
interested in it, but it does not clutter up the main recipe dir.
(and note again that I feel things like the ixp4xx and the ti codecs
etc do not fall into this group).

And yes: we can also try to repair them by finding alternate sources
etc (although this might be hard if someone changed from cvs to git).
Then again if the recipe has been broken for a long time, without
anyone taking action, filing a bug, reporting it on the list, I feel
that there is not really interest in that recipe any more and
personally I see it as a waste of time to try to repair them.

Frans

Re: some more non fetching recipes

[Martin Jansa]

On Mon, Sep 27, 2010 at 02:51:24PM +0200, Frans Meulenbroeks wrote:
> To clarify:
> Things that do not fetch because they require a manual download with
> accepting a license etc, I do not consider as broken.
> And of course we should keep these (I know the ixp4xx situation quite well).
> But how many of those do we have? I know about the ixp4xx and some ti
> ones. Maybe there are a few more that I missed but then again, most of
> the ~1000 recipes Martin mentioned and a lot of the recipes I listed
> above do not fall into this category but refer e.g. to a cvs server
> that is not there any more, to a version, tag or tarball that does not
> exist etc etc.
> 
> For me those recipes are broken. And if it is a recipe that is broken
> for a prolonged amount of time, there is apparently no interest in it,
> and personally I would like to have this indicated one way or another,
> or, even better, move these recipes into a dedicated folder(like
> nonworking). In that case the recipe is still there should somebody be
> interested in it, but it does not clutter up the main recipe dir.
> (and note again that I feel things like the ixp4xx and the ti codecs
> etc do not fall into this group).
> 
> And yes: we can also try to repair them by finding alternate sources
> etc (although this might be hard if someone changed from cvs to git).
> Then again if the recipe has been broken for a long time, without
> anyone taking action, filing a bug, reporting it on the list, I feel
> that there is not really interest in that recipe any more and
> personally I see it as a waste of time to try to repair them.

When I did this test, I've fixed those SRC_URI where I found new
location (usually moved to old subfolder etc.)

Then there was many recipes where original SRC_URI didn't work but I was 
able to find it with google ie 
http://familiar.handhelds.org/source/
was great source for really old releases, but I didn't change SRC_URIs
in this case because I don't know how long it will be there and it
doesn't feel like "proper" mirror. But because my main goal was to test
checksums I was moving to from checksums.ini to recipes it was enough
for me. And I didn't include those in my "download status" - but they
still cannot be downloaded (but at least I have them locally in
downloads dir).

Then there were other recipes where I wasn't able to find source
archive even with google (listed as 404 in status).

Some recipes with different checksums (then I kept checksums from
checksums.ini and noted that in status).

And worst case were recipes where original SRC_URI downloaded ie some
.html about domain no longer existing - which was detected as mismatched
checksums and needed manual check (those were also listed in status).

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: some more non fetching recipes

[Martin Jansa]

On Sun, Sep 26, 2010 at 12:21 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> Apart from the opensync and uclibc recipes that did not fetch and were
> reported before, I did get fetch issues for the files below.
> Haven't had time to dig into these, so some of these might be false alarms.
> If anyone feels attached to a recipe or can say something about it,
> please take action.
>
> Frans.
>
> PS: I removed the ti folder in this test; that one has recipes for
> which the SRC_URI seems to depend upon an external var (or vars) or
> which needed to be downloaded manually
>
> binutils/mingw-binutils-canadian-cross_2.20.bb
> binutils/mingw-binutils_2.20.bb
> bluez/bluez-gnome_cvs.bb
> cacao/cacao-native_hg.bb
> cumulus/cumulus_cvs.bb
> dpkg/dpkg-native_1.14.29.bb
> dpkg/dpkg_1.14.29.bb
> gpe-edit/gpe-edit_svn.bb
> gpsdrive/gpsdrive-pda_2.10pre2.bb
> gstreamer/gst-plugins-ugly-sid_0.10.7.bb
> hal/hal_git.bb
> kismet/kismet-newcore_svn.bb
> kismet/kismet_svn.bb
> konqueror/konqueror-embedded_20060404.bb
> linux-uml/linux-uml_2.4.26.bb
> linux-uml/linux-uml_2.6.11-rc2-mm1.bb
> maemo/nokia770-init_1.0.bb
> mamona/cx3110x-770he_0.8.1.bb
> mamona/cx3110x-chinooke_2.0.15.bb
> mamona/cx3110x-diablo_2.0.15.bb
> mamona/uinput_2.6.21.bb

> matchbox-panel/matchbox-panel_svn.bb
svn error with applets dir? it should be "fixed" by my last commit
forcing both recipes to use same SRCREV, but you have remove that svn
checkout manually once more (hopefully for last time)


> mplayer/mplayer-maemo_svn.bb
> musicpd/gmpc_svn.bb
> networkmanager/networkmanager_svn.bb

> openmoko-projects/paroli_git.bb
> openmoko-projects/tichy_git.bb
> openmoko2/openmoko-alsa-scenarios_svn.bb
> openmoko2/openmoko-contacts2_svn.bb
> openmoko2/openmoko-dates2_svn.bb
> openmoko2/openmoko-tasks2_svn.bb

I'll move those to nonworking if nobody complains (and remove those
from tasks depending on it)

> pidgin/msn-pecan_git.bb
> pimlico/contacts_svn.bb
> pimlico/dates_svn.bb
> pimlico/tasks_svn.bb
> powervr-drivers/bc-cube_0.1.0.bb
> powervr-drivers/bc-cube_0.2.0.bb
> powervr-drivers/libgles-omap3_3.01.00.02.bb
> powervr-drivers/libgles-omap3_3.01.00.06.bb
> powervr-drivers/libgles-omap3_3.01.00.07.bb
> powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> python/python-psyco_1.6.bb
> qt4/qt4-embedded-gles_4.6.0.bb
> qt4/qt4-embedded-gles_4.6.2.bb
> qt4/qt4-embedded-gles_4.6.3.bb
> qt4/qt4-x11-free-gles_4.5.2.bb
> qt4/qt4-x11-free-gles_4.6.0.bb
> qt4/qt4-x11-free-gles_4.6.2.bb
> qt4/qt4-x11-free-gles_4.6.3.bb
> qt4/qt4-x11-free-gles_4.7.0.bb

for qt4-x11-free-gles or whatever recipe including recipes/egl/egl.inc you need
COMPATIBLE_MACHINE = "omap3"
clearly we should add better error-handling for insuficient COMPATIBLE*

> rp-pppoe/rp-pppoe_3.5.bb
> schroedinger/gst-plugin-schroedinger_1.0.9.bb
> tinymail/libtinymail_svn.bb
> tinymail/tmut_svn.bb
> tinymail/libtinymail_svn.bb
> tinymail/tmut_svn.bb
> u-boot/u-boot-bug_svn.bb
> u-boot/u-boot-omap3beagleboard_1.1.4.bb
> u-boot/u-boot-omap3pandora_git.bb
> u-boot/u-boot_git.bb
> xffm/xffm_4.3.99.2.bb



> xorg-driver/xf86-input-vmmouse_12.6.10.bb
> xorg-driver/xf86-input-vmmouse_12.6.5.bb
> xorg-driver/xf86-video-geode_2.11.6.bb
> xorg-driver/xf86-video-geode_2.11.9.b


All 4 redownloaded OK, I guess you got

NOTE: Out of date cache found, rebuilding...
Command execution failed: Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/bb/command.py", line 88, in
runAsyncCommand
    commandmethod(self.cmds_async, self, options)
  File "/usr/lib64/python2.6/site-packages/bb/command.py", line 164,
in buildFile
    command.cooker.buildFile(bfile, task)
  File "/usr/lib64/python2.6/site-packages/bb/cooker.py", line 691, in buildFile
    self.status.task_deps[fn]['depends'] = {}
TypeError: 'NoneType' object does not support item assignment

because of: COMPATIBLE_HOST = "i.86.*-linux" in those 4 recipes..

Re: some more non fetching recipes

[Frans Meulenbroeks]

2010/10/3 Martin Jansa <martin.jansa@gmail.com>:

>
>> xorg-driver/xf86-input-vmmouse_12.6.10.bb
>> xorg-driver/xf86-input-vmmouse_12.6.5.bb
>> xorg-driver/xf86-video-geode_2.11.6.bb
>> xorg-driver/xf86-video-geode_2.11.9.b
>
>
> All 4 redownloaded OK, I guess you got
>
> NOTE: Out of date cache found, rebuilding...
> Command execution failed: Traceback (most recent call last):
>  File "/usr/lib64/python2.6/site-packages/bb/command.py", line 88, in
> runAsyncCommand
>    commandmethod(self.cmds_async, self, options)
>  File "/usr/lib64/python2.6/site-packages/bb/command.py", line 164,
> in buildFile
>    command.cooker.buildFile(bfile, task)
>  File "/usr/lib64/python2.6/site-packages/bb/cooker.py", line 691, in buildFile
>    self.status.task_deps[fn]['depends'] = {}
> TypeError: 'NoneType' object does not support item assignment
>
> because of: COMPATIBLE_HOST = "i.86.*-linux" in those 4 recipes..

Ah ok.
I got

ERROR: Command execution failed: Traceback (most recent call last):
  File "/home/frans/oe/bitbake/lib/bb/command.py", line 88, in runAsyncCommand
    commandmethod(self.cmds_async, self, options)
  File "/home/frans/oe/bitbake/lib/bb/command.py", line 174, in buildFile
    command.cooker.buildFile(bfile, task)
  File "/home/frans/oe/bitbake/lib/bb/cooker.py", line 650, in buildFile
    self.status.task_deps[fn]['depends'] = {}
TypeError: 'NoneType' object does not support item assignment

and indeed I did not use an *86 target.
Guess we need a better error message here
Something like:
NOTE: the recipe you are trying to build does not match your
machine/architecture"

Frans