QA Goals for OpenEmbedded

QA Goals for OpenEmbedded

[Holger Hans Peter Freyther]

Hi all,

mostly inspired by Guo's last mail about buildbot. In one way I agree with 
Guo, we need more QA and also an attitute to not commit when the tree is 
somehow broken...


Here is my list of short term goals and it would be cool if people sign up for 
it:


	*) Does bitbake world work? If not it would be cool if someone could take
            a look?

        *) Fix compile errors of bitbake world for a set of configurations?

	*) Koen reported that dependency loop reporting is not working anymore..
            anyone cares to invest thes five minutes to fix that?

	*) Sometimes we have pretty embarassing issues like some images switching
            from mdev back to udev and we don't notice for months(!!!)
            It would totally rock if one could change the rootfs.bbclass (or
            such) class and count the size of the image on the first run, store 
            it in the temp directory and report the diff's back to the 
            tinderbox and then we could have a view on the tinderbox?

            Inside the build summary we should see the new size of the image
            and the growth compared to the first built?

            The idea would be to have people look at the waterfall and go OMG 
            why did "minimal-image" grow by 2MB?

          *) The next step would be to transfer packet sizes as well

	  *) Integrate some testing into recipes. E.g. attempt to boot the console-
             image and grep the Serial Console for the "Loging:" prompt..
             Test the toolchain to compile binaries...



anyone feels like helping?
	z.

Re: QA Goals for OpenEmbedded

[Frans Meulenbroeks]

2010/1/6 Holger Hans Peter Freyther <holger+oe@freyther.de>:
> Hi all,
>
> mostly inspired by Guo's last mail about buildbot. In one way I agree with
> Guo, we need more QA and also an attitute to not commit when the tree is
> somehow broken...
>
>
> Here is my list of short term goals and it would be cool if people sign up for
> it:
>
>
>        *) Does bitbake world work? If not it would be cool if someone could take
>            a look?
>
>        *) Fix compile errors of bitbake world for a set of configurations?
>
>        *) Koen reported that dependency loop reporting is not working anymore..
>            anyone cares to invest thes five minutes to fix that?
>
>        *) Sometimes we have pretty embarassing issues like some images switching
>            from mdev back to udev and we don't notice for months(!!!)
>            It would totally rock if one could change the rootfs.bbclass (or
>            such) class and count the size of the image on the first run, store
>            it in the temp directory and report the diff's back to the
>            tinderbox and then we could have a view on the tinderbox?
>
>            Inside the build summary we should see the new size of the image
>            and the growth compared to the first built?
>
>            The idea would be to have people look at the waterfall and go OMG
>            why did "minimal-image" grow by 2MB?
>
>          *) The next step would be to transfer packet sizes as well
>
>          *) Integrate some testing into recipes. E.g. attempt to boot the console-
>             image and grep the Serial Console for the "Loging:" prompt..
>             Test the toolchain to compile binaries...
>
>
>
> anyone feels like helping?
>        z.

Holger, I'm always open to helping (time permitting of course).

Another thing I found missing is the lack of error messages in the
classes if e.g. a file is missing. In some cases this seems to be
silently ignored.
Had a case yesterday (will report on it in a separate message) and
also saw it on a different place to report (but forgot to note it and
can't recall it, sorry).

Frans

(btw dependency testing worked for me a few days ago, but that was on
a tree that was not in the dev head).

Frans.

Re: QA Goals for OpenEmbedded

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06-01-10 05:07, Holger Hans Peter Freyther wrote:

> 
> 	*) Sometimes we have pretty embarassing issues like some images switching
>             from mdev back to udev and we don't notice for months(!!!)
>             It would totally rock if one could change the rootfs.bbclass (or
>             such) class and count the size of the image on the first run, store 
>             it in the temp directory and report the diff's back to the 
>             tinderbox and then we could have a view on the tinderbox?
> 
>             Inside the build summary we should see the new size of the image
>             and the growth compared to the first built?
> 
>             The idea would be to have people look at the waterfall and go OMG 
>             why did "minimal-image" grow by 2MB?
> 
>           *) The next step would be to transfer packet sizes as well
> 
> 	  *) Integrate some testing into recipes. E.g. attempt to boot the console-
>              image and grep the Serial Console for the "Loging:" prompt..
>              Test the toolchain to compile binaries...

Those 3 points are exactly what testlab.bbclass was created for :) Over
2 years old now, but illustrates the usefullness of that class:
http://dominion.thruhere.net/koen/cms/the-testlab-strikes-again

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLREcwMkyGM64RGpERAquMAJ0ew07LQRZutS5gu6vCIvmyukEEAgCeJ6Lx
/4mvjNmmqeVP6TbVl8pRSYY=
=qUTY
-----END PGP SIGNATURE-----

Re: QA Goals for OpenEmbedded

[Richard Purdie]

On Wed, 2010-01-06 at 05:07 +0100, Holger Hans Peter Freyther wrote:
> 	*) Koen reported that dependency loop reporting is not working anymore..
>             anyone cares to invest thes five minutes to fix that?

In bitbake?

> 	*) Sometimes we have pretty embarassing issues like some images switching
>             from mdev back to udev and we don't notice for months(!!!)
>             It would totally rock if one could change the rootfs.bbclass (or
>             such) class and count the size of the image on the first run, store 
>             it in the temp directory and report the diff's back to the 
>             tinderbox and then we could have a view on the tinderbox?
> 
>             Inside the build summary we should see the new size of the image
>             and the growth compared to the first built?
> 
>             The idea would be to have people look at the waterfall and go OMG 
>             why did "minimal-image" grow by 2MB?

I started packagehistory.bbclass in Poky with ideas like this in mind.
It stores data in a filesystem layout and checked package versions don't
go backwards. Adding transports to send and receive data from a database
server would be a nice improvement.

>           *) The next step would be to transfer packet sizes as well

package sizes? Again this was a goal for packagehistory.bbclass


Cheers,

Richard

Re: QA Goals for OpenEmbedded

[Martin Jansa]

On Wed, Jan 06, 2010 at 03:26:41PM +0000, Richard Purdie wrote:
> On Wed, 2010-01-06 at 05:07 +0100, Holger Hans Peter Freyther wrote:
> > 	*) Koen reported that dependency loop reporting is not working anymore..
> >             anyone cares to invest thes five minutes to fix that?
> 
> In bitbake?

I've seen that too on the same case as Koen, for me it didn't fail
visibly, but after saying that it runs dependency loop detection it
hanged for about 20 mins still working.. then I killed it...

Dependency loop between bitbake tasks was resolved ok and fast (last
time I was changing do_deploy position in kernel.bbclass).

> > 	*) Sometimes we have pretty embarassing issues like some images switching
> >             from mdev back to udev and we don't notice for months(!!!)
> >             It would totally rock if one could change the rootfs.bbclass (or
> >             such) class and count the size of the image on the first run, store 
> >             it in the temp directory and report the diff's back to the 
> >             tinderbox and then we could have a view on the tinderbox?
> > 
> >             Inside the build summary we should see the new size of the image
> >             and the growth compared to the first built?
> > 
> >             The idea would be to have people look at the waterfall and go OMG 
> >             why did "minimal-image" grow by 2MB?
> 
> I started packagehistory.bbclass in Poky with ideas like this in mind.
> It stores data in a filesystem layout and checked package versions don't
> go backwards. Adding transports to send and receive data from a database
> server would be a nice improvement.
> 
> >           *) The next step would be to transfer packet sizes as well
> 
> package sizes? Again this was a goal for packagehistory.bbclass

Maybe not as much QA as above examples, but would be nice to add .md5
sums not only to downloaded sources but also to generated files in
deploy dir (feeds are safe but images are created without).

I've checked kernel.bbclass and image.bbclass and it seems quite easy to
implement, should I prepare patch for that or is there something already?

Cheers,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: QA Goals for OpenEmbedded

[Rolf Leggewie]

Holger Hans Peter Freyther wrote:
> 	*) Does bitbake world work? If not it would be cool if someone could take
>             a look?

I was hoping for bitbake world to work as a QA tool.  But my efforts on
the world target didn't really receive a warm welcome.  By now world is
so utterly broken that bitbake won't even ever start to execute any
tasks (I killed bitbake after two days when it still did nothing the
last time I tried).

Unfortunately, currently there is no consensus in OE that
"MACHINE=$machine bitbake $bb" shouldn't arbitrarily fail somewhere.
Right now, OE does not have the tools in place to specify that for
example $bb1 does not compile for $machineA (some people are very
allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
do versioned depends and so we can't say that $bb2-$version does not
compile with gcc less than 3.4.x, for example.  Those are just two
examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.

Re: QA Goals for OpenEmbedded

[Philip Balister]

On 01/06/2010 05:09 PM, Rolf Leggewie wrote:
> Holger Hans Peter Freyther wrote:
>> 	*) Does bitbake world work? If not it would be cool if someone could take
>>              a look?
>
> I was hoping for bitbake world to work as a QA tool.  But my efforts on
> the world target didn't really receive a warm welcome.  By now world is
> so utterly broken that bitbake won't even ever start to execute any
> tasks (I killed bitbake after two days when it still did nothing the
> last time I tried).

Can someone explain what bitbake world does?

I would be happier working toward a set of images building for a set of 
distributions.

Philip


>
> Unfortunately, currently there is no consensus in OE that
> "MACHINE=$machine bitbake $bb" shouldn't arbitrarily fail somewhere.
> Right now, OE does not have the tools in place to specify that for
> example $bb1 does not compile for $machineA (some people are very
> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
> do versioned depends and so we can't say that $bb2-$version does not
> compile with gcc less than 3.4.x, for example.  Those are just two
> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: QA Goals for OpenEmbedded

[Holger Hans Peter Freyther]

On Wednesday 06 January 2010 23:57:53 Philip Balister wrote:
> On 01/06/2010 05:09 PM, Rolf Leggewie wrote:
> > Holger Hans Peter Freyther wrote:
> >> 	*) Does bitbake world work? If not it would be cool if someone could
> >> take a look?
> >
> > I was hoping for bitbake world to work as a QA tool.  But my efforts on
> > the world target didn't really receive a warm welcome.  By now world is
> > so utterly broken that bitbake won't even ever start to execute any
> > tasks (I killed bitbake after two days when it still did nothing the
> > last time I tried).
> 
> Can someone explain what bitbake world does?
> 
> I would be happier working toward a set of images building for a set of
> distributions.

It should try to build all providers...

Re: QA Goals for OpenEmbedded

[Frans Meulenbroeks]

2010/1/6 Rolf Leggewie <no2spam@nospam.arcornews.de>:
> Holger Hans Peter Freyther wrote:
>>       *) Does bitbake world work? If not it would be cool if someone could take
>>             a look?
>
> I was hoping for bitbake world to work as a QA tool.  But my efforts on
> the world target didn't really receive a warm welcome.  By now world is
> so utterly broken that bitbake won't even ever start to execute any
> tasks (I killed bitbake after two days when it still did nothing the
> last time I tried).
>
> Unfortunately, currently there is no consensus in OE that
> "MACHINE=$machine bitbake $bb" shouldn't arbitrarily fail somewhere.

Ideally this should work.
However, in real life there are some restrictions.
e.g. if my machine is a sheevaplug (which does not have a display), it
is completely irrelevant whether Xserver or Qt compiles.

The current situation is though that someone needs or feels
responsible for a recipe and updates that (ideally after testing it on
all the hw he has :-) )
But it is way too cumbersome to build it for all other targets that
are out there. I would be more than happy if I could sent my recipe to
a build bot which then would build it for all kind of machines, and
give me a log to peek at afterwards.
But building locally for all kind of machines I do not own is simply
too resource (CPU and diskspace) consuming.

There are various ways to improve though.
We could enforce that changes first go to some automated QA process
before becoming "official".
Or we could have a notion somewhere which packages are tested/approved
for what machine
Or the recipe itself could state that (maybe even based upon this
automated build system)

I would suggest the TSC also to come up with an opinion on this.

My $ 0.02.

Frans.
> Right now, OE does not have the tools in place to specify that for
> example $bb1 does not compile for $machineA (some people are very
> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
> do versioned depends and so we can't say that $bb2-$version does not
> compile with gcc less than 3.4.x, for example.  Those are just two
> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: QA Goals for OpenEmbedded

[Graeme Gregory]

On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
> do versioned depends and so we can't say that $bb2-$version does not
> compile with gcc less than 3.4.x, for example.  Those are just two
> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
> 
No he didnt and no its not a hack. Its a blacklist of packages that for
various reasons Angstrom NEVER wants built.

Graeme

Re: QA Goals for OpenEmbedded

[Frans Meulenbroeks]

2010/1/7 Graeme Gregory <dp@xora.org.uk>:
> On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
>> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
>> do versioned depends and so we can't say that $bb2-$version does not
>> compile with gcc less than 3.4.x, for example.  Those are just two
>> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
>>
> No he didnt and no its not a hack. Its a blacklist of packages that for
> various reasons Angstrom NEVER wants built.

Should we have such a blacklist per machine?
My sheevaplug rungs angstrom, but as it has no display it has no need
for an X server, nor for ide or pci or sata tools.

Frans

Re: QA Goals for OpenEmbedded

[Graeme Gregory]

On Thu, Jan 07, 2010 at 09:50:36AM +0100, Frans Meulenbroeks wrote:
> 2010/1/7 Graeme Gregory <dp@xora.org.uk>:
> > On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
> >> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
> >> do versioned depends and so we can't say that $bb2-$version does not
> >> compile with gcc less than 3.4.x, for example.  Those are just two
> >> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
> >>
> > No he didnt and no its not a hack. Its a blacklist of packages that for
> > various reasons Angstrom NEVER wants built.
> 
> Should we have such a blacklist per machine?
> My sheevaplug rungs angstrom, but as it has no display it has no need
> for an X server, nor for ide or pci or sata tools.
> 
It follows the standard overide rules (or should do) so you should
be able to blacklist per machine.

Of course you chose a bad example as I know quite a few people are using
the sheeva with usb displaylink adapters.

Graeme

Re: QA Goals for OpenEmbedded

[Frans Meulenbroeks]

2010/1/7 Graeme Gregory <dp@xora.org.uk>:
> On Thu, Jan 07, 2010 at 09:50:36AM +0100, Frans Meulenbroeks wrote:
>> 2010/1/7 Graeme Gregory <dp@xora.org.uk>:
>> > On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
>> >> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
>> >> do versioned depends and so we can't say that $bb2-$version does not
>> >> compile with gcc less than 3.4.x, for example.  Those are just two
>> >> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
>> >>
>> > No he didnt and no its not a hack. Its a blacklist of packages that for
>> > various reasons Angstrom NEVER wants built.
>>
>> Should we have such a blacklist per machine?
>> My sheevaplug rungs angstrom, but as it has no display it has no need
>> for an X server, nor for ide or pci or sata tools.
>>
> It follows the standard overide rules (or should do) so you should
> be able to blacklist per machine.
>
> Of course you chose a bad example as I know quite a few people are using
> the sheeva with usb displaylink adapters.

Ah ok, I don't know any of them, but let's stay on safe grounds and
take pci or sata tools as an example ;-)

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

Re: QA Goals for OpenEmbedded

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07-01-10 10:35, Frans Meulenbroeks wrote:
> 2010/1/7 Graeme Gregory <dp@xora.org.uk>:
>> On Thu, Jan 07, 2010 at 09:50:36AM +0100, Frans Meulenbroeks wrote:
>>> 2010/1/7 Graeme Gregory <dp@xora.org.uk>:
>>>> On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
>>>>> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
>>>>> do versioned depends and so we can't say that $bb2-$version does not
>>>>> compile with gcc less than 3.4.x, for example.  Those are just two
>>>>> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
>>>>>
>>>> No he didnt and no its not a hack. Its a blacklist of packages that for
>>>> various reasons Angstrom NEVER wants built.
>>>
>>> Should we have such a blacklist per machine?
>>> My sheevaplug rungs angstrom, but as it has no display it has no need
>>> for an X server, nor for ide or pci or sata tools.
>>>
>> It follows the standard overide rules (or should do) so you should
>> be able to blacklist per machine.
>>
>> Of course you chose a bad example as I know quite a few people are using
>> the sheeva with usb displaylink adapters.
> 
> Ah ok, I don't know any of them, but let's stay on safe grounds and
> take pci or sata tools as an example ;-)

You don't like usb2sata adaptors?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLRawjMkyGM64RGpERAoFSAKCds8QU/tPv0gOIpDIshm1FZ/cJVQCgnoMl
3J3CPrd7P7UyYBDhCOebPfQ=
=cmr3
-----END PGP SIGNATURE-----

Re: QA Goals for OpenEmbedded

[Frans Meulenbroeks]

2010/1/7 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07-01-10 10:35, Frans Meulenbroeks wrote:
>> 2010/1/7 Graeme Gregory <dp@xora.org.uk>:
>>> On Thu, Jan 07, 2010 at 09:50:36AM +0100, Frans Meulenbroeks wrote:
>>>> 2010/1/7 Graeme Gregory <dp@xora.org.uk>:
>>>>> On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
>>>>>> allergic to COMPATIBLE_MACHINE for no particular reason).  Bitbake can't
>>>>>> do versioned depends and so we can't say that $bb2-$version does not
>>>>>> compile with gcc less than 3.4.x, for example.  Those are just two
>>>>>> examples.  XorA "solved" this in a hackish way with angsstrom.bbclass.
>>>>>>
>>>>> No he didnt and no its not a hack. Its a blacklist of packages that for
>>>>> various reasons Angstrom NEVER wants built.
>>>>
>>>> Should we have such a blacklist per machine?
>>>> My sheevaplug rungs angstrom, but as it has no display it has no need
>>>> for an X server, nor for ide or pci or sata tools.
>>>>
>>> It follows the standard overide rules (or should do) so you should
>>> be able to blacklist per machine.
>>>
>>> Of course you chose a bad example as I know quite a few people are using
>>> the sheeva with usb displaylink adapters.
>>
>> Ah ok, I don't know any of them, but let's stay on safe grounds and
>> take pci or sata tools as an example ;-)
>
> You don't like usb2sata adaptors?

Ok the grounds were not as safe as I hoped  :-)
Do they expose as sata drives? I know about usb2sata adaptors to
connect a sata disk via usb, but afaik it shows to the system as a usb
peripheral not as a sata peripheral.

Guess pci is a safer example (but if someone knows a usb to pci or
mini-pci adaptor I'd be glad to learn about it).

And sorry for dragging this off-topic, but eventually probably the
question remains whether everything should be supported on every hw.
(I'm also thinking about sw like compiz, sw for dedicated, platform
specific hw (e.g. fpga), etc)

FM
>
> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFLRawjMkyGM64RGpERAoFSAKCds8QU/tPv0gOIpDIshm1FZ/cJVQCgnoMl
> 3J3CPrd7P7UyYBDhCOebPfQ=
> =cmr3
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: QA Goals for OpenEmbedded

[Rolf Leggewie]

Graeme Gregory wrote:
> On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
>> XorA "solved" this in a hackish way with angsstrom.bbclass.
>>
> No he didnt and no its not a hack.

He didn't?  On August 15th last year somebody in #oe with the nick
XorA|gone claimed he did.

http://www.hentges.net/irclogs/%23oe/2009/August/20090815_oe.log?lines=500#[20090815%2015:29:59]

<XorA|gone>: it is in the end why I wrote the generic blacklist code

and the following sounded rather hackish to me

<XorA|gone>: beware it gives a crazy python dump if you use it in combo
             with bitbake -b
[...]
<Laibsch>: OK, so not yet ready to be turned by default, he?
<XorA|gone>: Laibsch: any call to skippackage with bitbake -b does that
<XorA|gone>: Laibsch: as you rip out the recipe under bitbakes nose

As I said during that IRC chat I am of the opinion that OE needs a way
to specify tuples of for example PN/PV/DISTRO/MACHINE and maybe even the
version of gcc/binutils used that bitbake should not consider in the
task queue.  If the approach taken by angstrom.bbclass provides a proper
solution here it should be turned on by default. Comments welcome.  If
we had something like this in place I see a chance to resurrect "bitbake
world" and that would help a lot with QA (not saying that everybody
needs to build world all the time, but it would provide a good test).

Re: QA Goals for OpenEmbedded

[Graeme Gregory]

On Thu, Jan 07, 2010 at 11:40:39AM +0100, Rolf Leggewie wrote:
> Graeme Gregory wrote:
> > On Wed, Jan 06, 2010 at 11:09:10PM +0100, Rolf Leggewie wrote:
> >> XorA "solved" this in a hackish way with angsstrom.bbclass.
> >>
> > No he didnt and no its not a hack.
> 
> He didn't?  On August 15th last year somebody in #oe with the nick
> XorA|gone claimed he did.
> 
> http://www.hentges.net/irclogs/%23oe/2009/August/20090815_oe.log?lines=500#[20090815%2015:29:59]
> 
> <XorA|gone>: it is in the end why I wrote the generic blacklist code
> 
Any quote out of conext can mean anything :-) But in my conversation and now
the blacklist is to nuke a ${PN} without any consideration of versions or
dependencies. It is not and wasnt meant as a solution to versioned depends.

> and the following sounded rather hackish to me
> 
> <XorA|gone>: beware it gives a crazy python dump if you use it in combo
>              with bitbake -b
> [...]
> <Laibsch>: OK, so not yet ready to be turned by default, he?
> <XorA|gone>: Laibsch: any call to skippackage with bitbake -b does that
> <XorA|gone>: Laibsch: as you rip out the recipe under bitbakes nose
> 
bitbake deals badly when a PN dissapears during its execution as I said
on IRC it occurs also in a number of places where skippackage is called
including using COMPATIBLE_MACHINE. If blackist is hacky so is
COMPATIBLE_MACHINE.

Graeme