[PATCH] bluez-dtl1-workaround: remove PRIORITY

[PATCH] bluez-dtl1-workaround: remove PRIORITY

[Phil Blundell]

This one evaded the earlier mass removal due to extraneous trailing
whitespace.

Signed-off-by: Phil Blundell <philb@gnu.org>
---
 .../bluez/bluez-dtl1-workaround_1.0.bb             |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb b/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb
index b6b3d7d..103cfd9 100644
--- a/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb
+++ b/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb
@@ -1,8 +1,7 @@
 DESCRIPTION = "A nasty hack for for dtl1-cs driver to workaround suspend/resume."
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-SECTION = "console" 
-PRIORITY = "optional" 
+SECTION = "console"
 PR = "r3"
  
 SRC_URI = "file://02dtl1_cs.sh \
-- 
1.7.2.5

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Phil Blundell]

Or an alternative patch might be just to delete this recipe altogether.
Its sole purpose is to work around defects in hardware which must be the
best part of a decade old and I would be slightly surprised if anyone
was still using DTL1s in this day and age.

p.

On Tue, 2011-07-05 at 16:52 +0100, Phil Blundell wrote:
> This one evaded the earlier mass removal due to extraneous trailing
> whitespace.
> 
> Signed-off-by: Phil Blundell <philb@gnu.org>
> ---
>  .../bluez/bluez-dtl1-workaround_1.0.bb             |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb b/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb
> index b6b3d7d..103cfd9 100644
> --- a/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb
> +++ b/meta/recipes-connectivity/bluez/bluez-dtl1-workaround_1.0.bb
> @@ -1,8 +1,7 @@
>  DESCRIPTION = "A nasty hack for for dtl1-cs driver to workaround suspend/resume."
>  LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
> -SECTION = "console" 
> -PRIORITY = "optional" 
> +SECTION = "console"
>  PR = "r3"
>   
>  SRC_URI = "file://02dtl1_cs.sh \

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Paul Eggleton]

On Tuesday 05 July 2011 16:54:18 Phil Blundell wrote:
> Or an alternative patch might be just to delete this recipe altogether.
> Its sole purpose is to work around defects in hardware which must be the
> best part of a decade old and I would be slightly surprised if anyone
> was still using DTL1s in this day and age.

Is it possible some people are still using PCMCIA/CF cards with this hardware 
in it?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Koen Kooi]

Op 5 jul. 2011 om 17:31 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Tuesday 05 July 2011 16:54:18 Phil Blundell wrote:
>> Or an alternative patch might be just to delete this recipe altogether.
>> Its sole purpose is to work around defects in hardware which must be the
>> best part of a decade old and I would be slightly surprised if anyone
>> was still using DTL1s in this day and age.
> 
> Is it possible some people are still using PCMCIA/CF cards with this hardware 
> in it?

not that I'm using it, but there's one in my box with ipaq stuff :)


> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Phil Blundell]

On Tue, 2011-07-05 at 17:31 +0100, Paul Eggleton wrote:
> On Tuesday 05 July 2011 16:54:18 Phil Blundell wrote:
> > Or an alternative patch might be just to delete this recipe altogether.
> > Its sole purpose is to work around defects in hardware which must be the
> > best part of a decade old and I would be slightly surprised if anyone
> > was still using DTL1s in this day and age.
> 
> Is it possible some people are still using PCMCIA/CF cards with this hardware 
> in it?

It's certainly possible, yes.  But I don't think that the mere
possibility is a very strong argument for keeping the recipe in oe-core.
Maybe it would be better suited to meta-oe or some BSP layer,

I also have at least half a suspicion that the scripting in that recipe
is only compatible with 2.4 kernels anyway.

p.

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Paul Eggleton]

On Tuesday 05 July 2011 19:37:24 you wrote:
> On Tue, 2011-07-05 at 17:31 +0100, Paul Eggleton wrote:
> > Is it possible some people are still using PCMCIA/CF cards with this
> > hardware in it?
> 
> It's certainly possible, yes.  But I don't think that the mere
> possibility is a very strong argument for keeping the recipe in oe-core.
> Maybe it would be better suited to meta-oe or some BSP layer,

You're right, I guess it doesn't really belong in oe-core.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Saul Wold]

On 07/06/2011 07:06 AM, Paul Eggleton wrote:
> On Tuesday 05 July 2011 19:37:24 you wrote:
>> On Tue, 2011-07-05 at 17:31 +0100, Paul Eggleton wrote:
>>> Is it possible some people are still using PCMCIA/CF cards with this
>>> hardware in it?
>>
>> It's certainly possible, yes.  But I don't think that the mere
>> possibility is a very strong argument for keeping the recipe in oe-core.
>> Maybe it would be better suited to meta-oe or some BSP layer,
>
> You're right, I guess it doesn't really belong in oe-core.
>
Phil,

I will take a patch that deletes from here and adds it into the 
meta-extra's layer.

Sau!

> Cheers,
> Paul
>

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Phil Blundell]

On Wed, 2011-07-06 at 16:39 -0700, Saul Wold wrote:
> I will take a patch that deletes from here and adds it into the 
> meta-extra's layer.

OK.  What's meta-extra's?  I don't think I'm familiar with that layer.

p.

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Paul Eggleton]

On Thursday 07 July 2011 15:51:54 Phil Blundell wrote:
> On Wed, 2011-07-06 at 16:39 -0700, Saul Wold wrote:
> > I will take a patch that deletes from here and adds it into the
> > meta-extra's layer.
> 
> OK.  What's meta-extra's?  I don't think I'm familiar with that layer.

It's a Yocto layer that has been traditionally the place to preserve obsolete 
stuff that was removed from Poky.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-extras/

(FWIW, just noticed - I still haven't added the machine-specific stuff I removed 
from OE-core to meta-extras yet.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Phil Blundell]

On Thu, 2011-07-07 at 16:11 +0100, Paul Eggleton wrote:
> On Thursday 07 July 2011 15:51:54 Phil Blundell wrote:
> > On Wed, 2011-07-06 at 16:39 -0700, Saul Wold wrote:
> > > I will take a patch that deletes from here and adds it into the
> > > meta-extra's layer.
> > 
> > OK.  What's meta-extra's?  I don't think I'm familiar with that layer.
> 
> It's a Yocto layer that has been traditionally the place to preserve obsolete 
> stuff that was removed from Poky.
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-extras/

Ah, right, I see.

I've just sent a patch to this list to delete the recipe from oe-core.
I don't know where (or how) to send patches for meta-extras, but I guess
applying patch 2/2 in reverse against that repo would produce the
desired effect should anybody wish to do so.

p.

Re: [PATCH] bluez-dtl1-workaround: remove PRIORITY

[Darren Hart]

On 07/06/2011 04:39 PM, Saul Wold wrote:
> On 07/06/2011 07:06 AM, Paul Eggleton wrote:
>> On Tuesday 05 July 2011 19:37:24 you wrote:
>>> On Tue, 2011-07-05 at 17:31 +0100, Paul Eggleton wrote:
>>>> Is it possible some people are still using PCMCIA/CF cards with this
>>>> hardware in it?
>>>
>>> It's certainly possible, yes.  But I don't think that the mere
>>> possibility is a very strong argument for keeping the recipe in oe-core.
>>> Maybe it would be better suited to meta-oe or some BSP layer,
>>
>> You're right, I guess it doesn't really belong in oe-core.
>>
> Phil,
> 
> I will take a patch that deletes from here and adds it into the 
> meta-extra's layer.


In some cases this is simple enough to do - move one recipe from here to
there. In other cases, not so much. Note that in addition to the removal
of these recipes, Phil also kindly cleaned up kernel.bbclass by removing
a bunch of special casing that was in place for this specific module.
Adding that support to meta-extras is a considerable effort and not
particularly sustainable as more old-and-crusty code is purged from OE.
It is also not likely to be well tested, which makes meta-extra less and
less useful.

We need an exit-path for old-and-crusty code - the git repository has
the history, so if it's needed we can always pull it into meta-extras
and properly test it when we know there is an interest, but if some due
diligence has been performed to determine the code is no longer of any
use, it seems like a lot of effort for very little gain to move any and
all removal of code from oe-core to meta-extras.

Thanks,

Darren

> 
> Sau!
> 
>> Cheers,
>> Paul
>>
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel