[RFC][Zaurus] (Re)move obsolete kernels

[RFC][Zaurus] (Re)move obsolete kernels

[Andrea Adami]

I was testing a build for some Zaurus models (akita,spitz) and
re-discovered an old issue (oebug 4784):

NOTE: Resolving any missing task queue dependencies
ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity
'virtual/arm-angstrom-linux-gnueabi-gcc-2.95' but it wasn't found in any
PACKAGE or RPROVIDES variables
NOTE: Runtime target 'virtual/arm-angstrom-linux-gnueabi-gcc-2.95' is
unbuildable, removing...
Missing or unbuildable dependency chain was:
['virtual/arm-angstrom-linux-gnueabi-gcc-2.95']

The c7x0 model is already 'fixed' - no error
We know the error is not fatal but still...so, my proposal is to move
the old stuff to 'obsolete' or to patch the recipes as done for c7x0
(see a.m. bug).
This would lead to unbuildability of  'sharprom-compatible'
distro...which noone seems to be using now in 2009.

Other options?

Regards

Andrea

Re: [RFC][Zaurus] (Re)move obsolete kernels

[Rolf Leggewie]

Hi Andrea,,

Andrea Adami wrote:
> This would lead to unbuildability of  'sharprom-compatible'
> distro...which noone seems to be using now in 2009.

I don't know about all the issues involved here.  But from I understand, 
you are utterly breaking one thing to fix another which isn't really 
broken in the first place.

Gets my NACK, especially since I intend to revisit building 
SharpROM-compatible packages soon.

Regards

Rolf

Re: [RFC][Zaurus] (Re)move obsolete kernels

[Andrea Adami]

Rolf,

you know mine was a provocation...and a reminder for you.

Still some minor cleaning will be necessary (old recipes should not
pollute the build with unresolved dependencies).

Regards

Andrea


P.S. pls let me know about your results with sharprom-compatible.

Re: [RFC][Zaurus] (Re)move obsolete kernels

[Dmitry Eremin-Solenikov]

Andrea Adami wrote:

> This would lead to unbuildability of  'sharprom-compatible'
> distro...which noone seems to be using now in 2009.

Used two or three months ago.

-- 
With best wishes
Dmitry

Re: [RFC][Zaurus] (Re)move obsolete kernels

[Phil Blundell]

On Mon, 2009-05-25 at 11:29 +0200, Andrea Adami wrote:
> I was testing a build for some Zaurus models (akita,spitz) and
> re-discovered an old issue (oebug 4784):
> 
> NOTE: Resolving any missing task queue dependencies
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity
> 'virtual/arm-angstrom-linux-gnueabi-gcc-2.95' but it wasn't found in any
> PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'virtual/arm-angstrom-linux-gnueabi-gcc-2.95' is
> unbuildable, removing...
> Missing or unbuildable dependency chain was:
> ['virtual/arm-angstrom-linux-gnueabi-gcc-2.95']
> 
> The c7x0 model is already 'fixed' - no error
> We know the error is not fatal but still...so, my proposal is to move
> the old stuff to 'obsolete' or to patch the recipes as done for c7x0
> (see a.m. bug).
> This would lead to unbuildability of  'sharprom-compatible'
> distro...which noone seems to be using now in 2009.

I'm not quite sure what the issue is here.  Are you saying that you see
this diagnostic about gcc-2.95 even when the kernel that needs it isn't
selected for building?  If so, that seems like it would be a bitbake bug
and should be fixed as such.  (The fact that it's showing an empty list
for the dependent packages does indicate that something is a bit wrong
in bitbake, anyway.)

p.

Re: [RFC][Zaurus] (Re)move obsolete kernels

[Andrea Adami]

The culprit:

./openzaurus-pxa27x_2.4.20-rmk2-embedix20050602.bb:
COMPATIBLE_MACHINE = '(akita|spitz|borzoi)'

Discussing with Phil about the opportunity of using the defunct
'borzoi' as dummy target, he pointed out the following commit:

http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=52dcccdfd31b0b0c9ac4725dd52a20b88a6b7b7c


author	Richard Purdie <rpurdie@rpsys.net>	2006-04-08 19:18:40 (GMT)
committer	OpenEmbedded Project
<openembedded-devel@lists.openembedded.org>	2006-04-08 19:18:40 (GMT)
commit	52dcccdfd31b0b0c9ac4725dd52a20b88a6b7b7c (patch)
tree	06a634a182886ead6e16e3dad4fb1b3dc258ec4c
parent	5bcdb4abd61e4d64aec042d9bb27e8ff275530b3 (diff)
* Remove 2.4 machine support for c7x0, akita, spitz and borzoi.
* Remove borzoi machine entirely as its now equal to spitz. * For
remaining 2.4/2.6 split machines use ZKERNEL_VERSION instead of
KERNEL_VERSION to fix a long standing bug - people will need to update
local.conf. * Add dummy terrier MACHINE to point at spitz.


Thoughts?

Andrea