* Re: [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 4:00 [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes Joe MacDonald
@ 2017-02-24 4:55 ` Khem Raj
2017-02-24 9:16 ` Martin Jansa
2017-02-24 15:30 ` [PATCH v2] " Joe MacDonald
` (3 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: Khem Raj @ 2017-02-24 4:55 UTC (permalink / raw)
To: Joe MacDonald, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]
On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald <joe_macdonald@mentor.com>
wrote:
> Based on the blacklist behaviour, recipes can be tagged as deprecated.
> Such recipes will produce a warning message when included in a build but
> unlike blacklisted recipes, the build will continue.
Perhaps this should also be documented in manuals
>
>
> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> ---
>
> I threw this together a long time ago and never got around to sending it
> out for
> consideration, but after the excitement last week and this, I got thinking
> about
> it again and thought it might be useful. My specific use-case for this is
> recipes I see in meta-networking that I know are largely abandonware but
> that I
> don't want to completely throw out without giving some kind of heads up.
> Obviously this is purely informational, there's no mechanism set up for
> purging
> deprecated recipes, that's intended to be a maintainer activity, but the
> idea
> would be that the maintainer would flag a recipe as deprecated (probably
> when
> it's become more trouble than it seems to be worth) and thereafter users
> would
> have fair warning that this thing is on notice. If nobody speaks up
> within some
> amount of time the maintainer considers reasonable (I'm thinking a Yocto
> release
> cycle) then it's fair game to remove the recipe in question.
>
> meta/classes/deprecated.bbclass | 16 ++++++++++++++++
> meta/conf/distro/defaultsetup.conf | 3 ++-
> 2 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 meta/classes/deprecated.bbclass
>
> diff --git a/meta/classes/deprecated.bbclass
> b/meta/classes/deprecated.bbclass
> new file mode 100644
> index 0000000..3dcdadb
> --- /dev/null
> +++ b/meta/classes/deprecated.bbclass
> @@ -0,0 +1,16 @@
> +# To use the deprecated recipe check, a distribution should
> +# include this class in the INHERIT_DISTRO
> +#
> +# Features:
> +#
> +# * To add a package to the deprecated list, set:
> +# PNDEPRECATED[pn] = "message"
> +#
> +
> +addtask check_deprecated before do_fetch
> +python do_check_deprecated () {
> + deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
> +
> + if deprecated:
> + bb.warn("Recipe is deprecated: ", (deprecated))
> +}
> diff --git a/meta/conf/distro/defaultsetup.conf
> b/meta/conf/distro/defaultsetup.conf
> index ca2f917..16ece3a 100644
> --- a/meta/conf/distro/defaultsetup.conf
> +++ b/meta/conf/distro/defaultsetup.conf
> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/'
> + str(d.getVar('MACHINE'
> USER_CLASSES ?= ""
> PACKAGE_CLASSES ?= "package_ipk"
> INHERIT_BLACKLIST = "blacklist"
> +INHERIT_DEPRECATED = "deprecated"
> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> ${INHERIT_BLACKLIST}"
> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
> --
> 1.9.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 5448 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 4:55 ` Khem Raj
@ 2017-02-24 9:16 ` Martin Jansa
2017-02-24 20:39 ` Philip Balister
0 siblings, 1 reply; 12+ messages in thread
From: Martin Jansa @ 2017-02-24 9:16 UTC (permalink / raw)
To: Khem Raj; +Cc: Joe MacDonald, Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 4721 bytes --]
> If nobody speaks up within some
amount of time the maintainer considers reasonable (I'm thinking a Yocto
release
cycle) then it's fair game to remove the recipe in question.
Maybe this is different case with at least some PNBLACKLIST entries we
currently have, but
I don't remove PNBLACKLISTed recipes, because as we discussed it's always
easier to unblacklist
recipe from e.g. DISTRO config if the issue doesn't affect you for whatever
reason and causes
less churn in the metadata when it gets unblacklisted.
And many PNBLACKLISTed recipes are also abandonware.
So my question is, if we will remove PNDEPRECATed recipes after one cycle,
should we start
removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
cases it might backfire
when someone will fail to find recipe for his favorite abandonware and will
try to add completely
new recipe for it, or we see someone restoring these recipes (e.g. in own
layers instead of fixing
the PNBLACKLIST/PNDEPRECATED reasons in original layer).
On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald <joe_macdonald@mentor.com>
> wrote:
>
>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
>> Such recipes will produce a warning message when included in a build but
>> unlike blacklisted recipes, the build will continue.
>
>
> Perhaps this should also be documented in manuals
>
>>
>>
>> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
>> ---
>>
>> I threw this together a long time ago and never got around to sending it
>> out for
>> consideration, but after the excitement last week and this, I got
>> thinking about
>> it again and thought it might be useful. My specific use-case for this is
>> recipes I see in meta-networking that I know are largely abandonware but
>> that I
>> don't want to completely throw out without giving some kind of heads up.
>> Obviously this is purely informational, there's no mechanism set up for
>> purging
>> deprecated recipes, that's intended to be a maintainer activity, but the
>> idea
>> would be that the maintainer would flag a recipe as deprecated (probably
>> when
>> it's become more trouble than it seems to be worth) and thereafter users
>> would
>> have fair warning that this thing is on notice. If nobody speaks up
>> within some
>> amount of time the maintainer considers reasonable (I'm thinking a Yocto
>> release
>> cycle) then it's fair game to remove the recipe in question.
>>
>> meta/classes/deprecated.bbclass | 16 ++++++++++++++++
>> meta/conf/distro/defaultsetup.conf | 3 ++-
>> 2 files changed, 18 insertions(+), 1 deletion(-)
>> create mode 100644 meta/classes/deprecated.bbclass
>>
>> diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.
>> bbclass
>> new file mode 100644
>> index 0000000..3dcdadb
>> --- /dev/null
>> +++ b/meta/classes/deprecated.bbclass
>> @@ -0,0 +1,16 @@
>> +# To use the deprecated recipe check, a distribution should
>> +# include this class in the INHERIT_DISTRO
>> +#
>> +# Features:
>> +#
>> +# * To add a package to the deprecated list, set:
>> +# PNDEPRECATED[pn] = "message"
>> +#
>> +
>> +addtask check_deprecated before do_fetch
>> +python do_check_deprecated () {
>> + deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),
>> False)
>> +
>> + if deprecated:
>> + bb.warn("Recipe is deprecated: ", (deprecated))
>> +}
>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/
>> defaultsetup.conf
>> index ca2f917..16ece3a 100644
>> --- a/meta/conf/distro/defaultsetup.conf
>> +++ b/meta/conf/distro/defaultsetup.conf
>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['',
>> '/' + str(d.getVar('MACHINE'
>> USER_CLASSES ?= ""
>> PACKAGE_CLASSES ?= "package_ipk"
>> INHERIT_BLACKLIST = "blacklist"
>> +INHERIT_DEPRECATED = "deprecated"
>> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>> ${INHERIT_BLACKLIST}"
>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
>> --
>> 1.9.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
[-- Attachment #2: Type: text/html, Size: 9740 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 9:16 ` Martin Jansa
@ 2017-02-24 20:39 ` Philip Balister
2017-02-24 20:51 ` Martin Jansa
0 siblings, 1 reply; 12+ messages in thread
From: Philip Balister @ 2017-02-24 20:39 UTC (permalink / raw)
To: Martin Jansa, Khem Raj
Cc: Joe MacDonald, Patches and discussions about the oe-core layer
On 02/24/2017 01:16 AM, Martin Jansa wrote:
>> If nobody speaks up within some
> amount of time the maintainer considers reasonable (I'm thinking a Yocto
> release
> cycle) then it's fair game to remove the recipe in question.
>
> Maybe this is different case with at least some PNBLACKLIST entries we
> currently have, but
> I don't remove PNBLACKLISTed recipes, because as we discussed it's always
> easier to unblacklist
> recipe from e.g. DISTRO config if the issue doesn't affect you for whatever
> reason and causes
> less churn in the metadata when it gets unblacklisted.
>
> And many PNBLACKLISTed recipes are also abandonware.
>
I think we need to use a different "flag" for recipes that need
updating, and have maintained upstreams from recipes that have upstreams
that are abandoned.
So blacklist broken recipes with good upstreams and deprecate recipes
with dead upstreams.
Philip
> So my question is, if we will remove PNDEPRECATed recipes after one cycle,
> should we start
> removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
> cases it might backfire
> when someone will fail to find recipe for his favorite abandonware and will
> try to add completely
> new recipe for it, or we see someone restoring these recipes (e.g. in own
> layers instead of fixing
> the PNBLACKLIST/PNDEPRECATED reasons in original layer).
>
> On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald <joe_macdonald@mentor.com>
>> wrote:
>>
>>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
>>> Such recipes will produce a warning message when included in a build but
>>> unlike blacklisted recipes, the build will continue.
>>
>>
>> Perhaps this should also be documented in manuals
>>
>>>
>>>
>>> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
>>> ---
>>>
>>> I threw this together a long time ago and never got around to sending it
>>> out for
>>> consideration, but after the excitement last week and this, I got
>>> thinking about
>>> it again and thought it might be useful. My specific use-case for this is
>>> recipes I see in meta-networking that I know are largely abandonware but
>>> that I
>>> don't want to completely throw out without giving some kind of heads up.
>>> Obviously this is purely informational, there's no mechanism set up for
>>> purging
>>> deprecated recipes, that's intended to be a maintainer activity, but the
>>> idea
>>> would be that the maintainer would flag a recipe as deprecated (probably
>>> when
>>> it's become more trouble than it seems to be worth) and thereafter users
>>> would
>>> have fair warning that this thing is on notice. If nobody speaks up
>>> within some
>>> amount of time the maintainer considers reasonable (I'm thinking a Yocto
>>> release
>>> cycle) then it's fair game to remove the recipe in question.
>>>
>>> meta/classes/deprecated.bbclass | 16 ++++++++++++++++
>>> meta/conf/distro/defaultsetup.conf | 3 ++-
>>> 2 files changed, 18 insertions(+), 1 deletion(-)
>>> create mode 100644 meta/classes/deprecated.bbclass
>>>
>>> diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.
>>> bbclass
>>> new file mode 100644
>>> index 0000000..3dcdadb
>>> --- /dev/null
>>> +++ b/meta/classes/deprecated.bbclass
>>> @@ -0,0 +1,16 @@
>>> +# To use the deprecated recipe check, a distribution should
>>> +# include this class in the INHERIT_DISTRO
>>> +#
>>> +# Features:
>>> +#
>>> +# * To add a package to the deprecated list, set:
>>> +# PNDEPRECATED[pn] = "message"
>>> +#
>>> +
>>> +addtask check_deprecated before do_fetch
>>> +python do_check_deprecated () {
>>> + deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),
>>> False)
>>> +
>>> + if deprecated:
>>> + bb.warn("Recipe is deprecated: ", (deprecated))
>>> +}
>>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/
>>> defaultsetup.conf
>>> index ca2f917..16ece3a 100644
>>> --- a/meta/conf/distro/defaultsetup.conf
>>> +++ b/meta/conf/distro/defaultsetup.conf
>>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['',
>>> '/' + str(d.getVar('MACHINE'
>>> USER_CLASSES ?= ""
>>> PACKAGE_CLASSES ?= "package_ipk"
>>> INHERIT_BLACKLIST = "blacklist"
>>> +INHERIT_DEPRECATED = "deprecated"
>>> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>>> ${INHERIT_BLACKLIST}"
>>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
>>> --
>>> 1.9.1
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 20:39 ` Philip Balister
@ 2017-02-24 20:51 ` Martin Jansa
2017-02-27 13:50 ` Joe MacDonald
0 siblings, 1 reply; 12+ messages in thread
From: Martin Jansa @ 2017-02-24 20:51 UTC (permalink / raw)
To: Philip Balister
Cc: Joe MacDonald, Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 5837 bytes --]
OK, should I update all currently PNBLACKLISTed recipes to add " - the
recipe will be removed on 2017-09-01 unless the issue is fixed" in the
PNBLACKLIST value, so that we can delete all blacklisted recipes before 2.4
release?
On Fri, Feb 24, 2017 at 9:39 PM, Philip Balister <philip@balister.org>
wrote:
> On 02/24/2017 01:16 AM, Martin Jansa wrote:
> >> If nobody speaks up within some
> > amount of time the maintainer considers reasonable (I'm thinking a Yocto
> > release
> > cycle) then it's fair game to remove the recipe in question.
> >
> > Maybe this is different case with at least some PNBLACKLIST entries we
> > currently have, but
> > I don't remove PNBLACKLISTed recipes, because as we discussed it's always
> > easier to unblacklist
> > recipe from e.g. DISTRO config if the issue doesn't affect you for
> whatever
> > reason and causes
> > less churn in the metadata when it gets unblacklisted.
> >
> > And many PNBLACKLISTed recipes are also abandonware.
> >
>
> I think we need to use a different "flag" for recipes that need
> updating, and have maintained upstreams from recipes that have upstreams
> that are abandoned.
>
> So blacklist broken recipes with good upstreams and deprecate recipes
> with dead upstreams.
>
> Philip
>
>
>
> > So my question is, if we will remove PNDEPRECATed recipes after one
> cycle,
> > should we start
> > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
> > cases it might backfire
> > when someone will fail to find recipe for his favorite abandonware and
> will
> > try to add completely
> > new recipe for it, or we see someone restoring these recipes (e.g. in own
> > layers instead of fixing
> > the PNBLACKLIST/PNDEPRECATED reasons in original layer).
> >
> > On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj <raj.khem@gmail.com> wrote:
> >
> >>
> >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald <joe_macdonald@mentor.com
> >
> >> wrote:
> >>
> >>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
> >>> Such recipes will produce a warning message when included in a build
> but
> >>> unlike blacklisted recipes, the build will continue.
> >>
> >>
> >> Perhaps this should also be documented in manuals
> >>
> >>>
> >>>
> >>> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >>> ---
> >>>
> >>> I threw this together a long time ago and never got around to sending
> it
> >>> out for
> >>> consideration, but after the excitement last week and this, I got
> >>> thinking about
> >>> it again and thought it might be useful. My specific use-case for
> this is
> >>> recipes I see in meta-networking that I know are largely abandonware
> but
> >>> that I
> >>> don't want to completely throw out without giving some kind of heads
> up.
> >>> Obviously this is purely informational, there's no mechanism set up for
> >>> purging
> >>> deprecated recipes, that's intended to be a maintainer activity, but
> the
> >>> idea
> >>> would be that the maintainer would flag a recipe as deprecated
> (probably
> >>> when
> >>> it's become more trouble than it seems to be worth) and thereafter
> users
> >>> would
> >>> have fair warning that this thing is on notice. If nobody speaks up
> >>> within some
> >>> amount of time the maintainer considers reasonable (I'm thinking a
> Yocto
> >>> release
> >>> cycle) then it's fair game to remove the recipe in question.
> >>>
> >>> meta/classes/deprecated.bbclass | 16 ++++++++++++++++
> >>> meta/conf/distro/defaultsetup.conf | 3 ++-
> >>> 2 files changed, 18 insertions(+), 1 deletion(-)
> >>> create mode 100644 meta/classes/deprecated.bbclass
> >>>
> >>> diff --git a/meta/classes/deprecated.bbclass
> b/meta/classes/deprecated.
> >>> bbclass
> >>> new file mode 100644
> >>> index 0000000..3dcdadb
> >>> --- /dev/null
> >>> +++ b/meta/classes/deprecated.bbclass
> >>> @@ -0,0 +1,16 @@
> >>> +# To use the deprecated recipe check, a distribution should
> >>> +# include this class in the INHERIT_DISTRO
> >>> +#
> >>> +# Features:
> >>> +#
> >>> +# * To add a package to the deprecated list, set:
> >>> +# PNDEPRECATED[pn] = "message"
> >>> +#
> >>> +
> >>> +addtask check_deprecated before do_fetch
> >>> +python do_check_deprecated () {
> >>> + deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),
> >>> False)
> >>> +
> >>> + if deprecated:
> >>> + bb.warn("Recipe is deprecated: ", (deprecated))
> >>> +}
> >>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/
> >>> defaultsetup.conf
> >>> index ca2f917..16ece3a 100644
> >>> --- a/meta/conf/distro/defaultsetup.conf
> >>> +++ b/meta/conf/distro/defaultsetup.conf
> >>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['',
> >>> '/' + str(d.getVar('MACHINE'
> >>> USER_CLASSES ?= ""
> >>> PACKAGE_CLASSES ?= "package_ipk"
> >>> INHERIT_BLACKLIST = "blacklist"
> >>> +INHERIT_DEPRECATED = "deprecated"
> >>> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
> >>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> >>> ${INHERIT_BLACKLIST}"
> >>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> >>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
> >>> --
> >>> 1.9.1
> >>>
> >>> --
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>>
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
> >>
> >
> >
> >
>
[-- Attachment #2: Type: text/html, Size: 8246 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 20:51 ` Martin Jansa
@ 2017-02-27 13:50 ` Joe MacDonald
0 siblings, 0 replies; 12+ messages in thread
From: Joe MacDonald @ 2017-02-27 13:50 UTC (permalink / raw)
To: Martin Jansa; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 7190 bytes --]
[Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes] On 17.02.24 (Fri 21:51) Martin Jansa wrote:
> OK, should I update all currently PNBLACKLISTed recipes to add " - the
> recipe will be removed on 2017-09-01 unless the issue is fixed" in the
> PNBLACKLIST value, so that we can delete all blacklisted recipes
> before 2.4 release?
I haven't seen any additional discussion on this yet but my personal
opinion on this is it seems reasonable to draw a line in the sand and
one that's quite far out. I also expect that there'll be a flurry of
activity as the deadline draws close, so there's room for flexibility in
the drop-dead date, but that'd be a discretionary thing. If we wanted
to be slightly less contentious, the wording could be 'may' rather than
'will' and then the message is "if it isn't fixed by this date, it's
fair game to be removed whenever someone gets around to it".
-J.
>
> On Fri, Feb 24, 2017 at 9:39 PM, Philip Balister <philip@balister.org> wrote:
>
> On 02/24/2017 01:16 AM, Martin Jansa wrote:
> >> If nobody speaks up within some
> > amount of time the maintainer considers reasonable (I'm thinking a Yocto
> > release
> > cycle) then it's fair game to remove the recipe in question.
> >
> > Maybe this is different case with at least some PNBLACKLIST entries we
> > currently have, but
> > I don't remove PNBLACKLISTed recipes, because as we discussed it's always
> > easier to unblacklist
> > recipe from e.g. DISTRO config if the issue doesn't affect you for
> whatever
> > reason and causes
> > less churn in the metadata when it gets unblacklisted.
> >
> > And many PNBLACKLISTed recipes are also abandonware.
> >
>
> I think we need to use a different "flag" for recipes that need
> updating, and have maintained upstreams from recipes that have upstreams
> that are abandoned.
>
> So blacklist broken recipes with good upstreams and deprecate recipes
> with dead upstreams.
>
> Philip
>
>
>
> > So my question is, if we will remove PNDEPRECATed recipes after one
> cycle,
> > should we start
> > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
> > cases it might backfire
> > when someone will fail to find recipe for his favorite abandonware and
> will
> > try to add completely
> > new recipe for it, or we see someone restoring these recipes (e.g. in own
> > layers instead of fixing
> > the PNBLACKLIST/PNDEPRECATED reasons in original layer).
> >
> > On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj <raj.khem@gmail.com> wrote:
> >
> >>
> >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald <joe_macdonald@mentor.com>
> >> wrote:
> >>
> >>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
> >>> Such recipes will produce a warning message when included in a build
> but
> >>> unlike blacklisted recipes, the build will continue.
> >>
> >>
> >> Perhaps this should also be documented in manuals
> >>
> >>>
> >>>
> >>> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >>> ---
> >>>
> >>> I threw this together a long time ago and never got around to sending
> it
> >>> out for
> >>> consideration, but after the excitement last week and this, I got
> >>> thinking about
> >>> it again and thought it might be useful. My specific use-case for this
> is
> >>> recipes I see in meta-networking that I know are largely abandonware
> but
> >>> that I
> >>> don't want to completely throw out without giving some kind of heads
> up.
> >>> Obviously this is purely informational, there's no mechanism set up for
> >>> purging
> >>> deprecated recipes, that's intended to be a maintainer activity, but
> the
> >>> idea
> >>> would be that the maintainer would flag a recipe as deprecated
> (probably
> >>> when
> >>> it's become more trouble than it seems to be worth) and thereafter
> users
> >>> would
> >>> have fair warning that this thing is on notice. If nobody speaks up
> >>> within some
> >>> amount of time the maintainer considers reasonable (I'm thinking a
> Yocto
> >>> release
> >>> cycle) then it's fair game to remove the recipe in question.
> >>>
> >>> meta/classes/deprecated.bbclass | 16 ++++++++++++++++
> >>> meta/conf/distro/defaultsetup.conf | 3 ++-
> >>> 2 files changed, 18 insertions(+), 1 deletion(-)
> >>> create mode 100644 meta/classes/deprecated.bbclass
> >>>
> >>> diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.
> >>> bbclass
> >>> new file mode 100644
> >>> index 0000000..3dcdadb
> >>> --- /dev/null
> >>> +++ b/meta/classes/deprecated.bbclass
> >>> @@ -0,0 +1,16 @@
> >>> +# To use the deprecated recipe check, a distribution should
> >>> +# include this class in the INHERIT_DISTRO
> >>> +#
> >>> +# Features:
> >>> +#
> >>> +# * To add a package to the deprecated list, set:
> >>> +# PNDEPRECATED[pn] = "message"
> >>> +#
> >>> +
> >>> +addtask check_deprecated before do_fetch
> >>> +python do_check_deprecated () {
> >>> + deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),
> >>> False)
> >>> +
> >>> + if deprecated:
> >>> + bb.warn("Recipe is deprecated: ", (deprecated))
> >>> +}
> >>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/
> >>> defaultsetup.conf
> >>> index ca2f917..16ece3a 100644
> >>> --- a/meta/conf/distro/defaultsetup.conf
> >>> +++ b/meta/conf/distro/defaultsetup.conf
> >>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['',
> >>> '/' + str(d.getVar('MACHINE'
> >>> USER_CLASSES ?= ""
> >>> PACKAGE_CLASSES ?= "package_ipk"
> >>> INHERIT_BLACKLIST = "blacklist"
> >>> +INHERIT_DEPRECATED = "deprecated"
> >>> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
> >>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> >>> ${INHERIT_BLACKLIST}"
> >>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> >>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
> >>> --
> >>> 1.9.1
> >>>
> >>> --
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>>
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
> >>
> >
> >
> >
>
>
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 4:00 [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes Joe MacDonald
2017-02-24 4:55 ` Khem Raj
@ 2017-02-24 15:30 ` Joe MacDonald
2017-02-27 13:59 ` [PATCH v3] " Joe MacDonald
` (2 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Joe MacDonald @ 2017-02-24 15:30 UTC (permalink / raw)
To: openembedded-core
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
---
documentation/ref-manual/ref-classes.xml | 28 ++++++++++++++++++++++++++++
documentation/ref-manual/ref-variables.xml | 28 ++++++++++++++++++++++++++++
meta/classes/deprecated.bbclass | 16 ++++++++++++++++
meta/conf/distro/defaultsetup.conf | 3 ++-
4 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/deprecated.bbclass
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
index f7b1126..6088b44 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -632,6 +632,34 @@
</para>
</section>
+<section id='ref-classes-deprecated'>
+ <title><filename>deprecated.bbclass</filename></title>
+
+ <para>
+ The <filename>deprecated</filename> class identifies recipes
+ that for one reason or another are being considered for removal
+ from their current layer. It may be due to persistent, known
+ issues with the package, that there are newer, more feature-rich
+ alternatives available in the same layer or that the recipe is
+ no longer needed. The recipe should provide a reason for the
+ depercation and a suggestion to consumers of the recipe as to how
+ to proceed.
+ To use this class, inherit the class globally and set
+ <link linkend='var-PNDEPRECATED'><filename>PNDEPRECATED</filename></link>
+ for each recipe you intend to deprecate.
+ Specify the <link linkend='var-PN'><filename>PN</filename></link>
+ value as a variable flag (varflag) and provide a reason, which is
+ reported, if the package is requested to be built as the value.
+ For example, if you want to deprecate a recipe called "exoticware",
+ you add the following to your <filename>local.conf</filename>
+ or distribution configuration:
+ <literallayout class='monospaced'>
+ INHERIT += "deprecated"
+ PNDEPRECATED[exoticware] = "'exoticware' is considered obsolete and has been replaced by 'standardware'. 'exoticware' may not appear in future releases."
+ </literallayout>
+ </para>
+</section>
+
<section id='ref-classes-devshell'>
<title><filename>devshell.bbclass</filename></title>
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index f79cdd2..629d167 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -9920,6 +9920,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
</glossdef>
</glossentry>
+ <glossentry id='var-PNDEPRECATED'><glossterm>PNDEPRECATED</glossterm>
+ <info>
+ PNDEPRECATED[doc] = "Lists recipes that may be removed in a future release or have more actively maintained alternatives."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Lists recipes that may be removed in a future release or
+ have more actively maintained alternatives.
+ This variable works in conjunction with the
+ <link linkend='ref-classes-deprecated'><filename>deprecated</filename></link>
+ class, which the recipe must inherit globally.
+ </para>
+
+ <para>
+ To identify a recipe as deprecated, inherit the class
+ globally and use the variable in your
+ <filename>local.conf</filename> file.
+ Here is an example that will show a warning when
+ <filename>myrecipe</filename> is included in a project:
+ <literallayout class='monospaced'>
+ INHERIT += "deprecated"
+ PNDEPRECATED[myrecipe] = "Recipe is no longer actively maintained, you should consider using 'mynewrecipe' as an alternative."
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-POPULATE_SDK_POST_HOST_COMMAND'><glossterm>POPULATE_SDK_POST_HOST_COMMAND</glossterm>
<info>
POPULATE_SDK_POST_HOST_COMMAND[doc] = "Specifies a list of functions to call once the OpenEmbedded build system has created host part of the SDK."
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 0000000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+# PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+ deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+ if deprecated:
+ bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + str(d.getVar('MACHINE'
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
-INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
--
1.9.1
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v3] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 4:00 [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes Joe MacDonald
2017-02-24 4:55 ` Khem Raj
2017-02-24 15:30 ` [PATCH v2] " Joe MacDonald
@ 2017-02-27 13:59 ` Joe MacDonald
[not found] ` <20170227183329.9748.13885@do.openembedded.org>
2017-03-03 13:57 ` [PATCH v4] deprecated.bbclass: Add a PNDEPRECATED variable for recipes Joe MacDonald
4 siblings, 0 replies; 12+ messages in thread
From: Joe MacDonald @ 2017-02-27 13:59 UTC (permalink / raw)
To: openembedded-core
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
---
v2: Included documentation for new variable
v3: Refreshed to address patchwork scolding
documentation/ref-manual/ref-classes.xml | 28 ++++++++++++++++++++++++++++
documentation/ref-manual/ref-variables.xml | 28 ++++++++++++++++++++++++++++
meta/classes/deprecated.bbclass | 16 ++++++++++++++++
meta/conf/distro/defaultsetup.conf | 3 ++-
4 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/deprecated.bbclass
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
index f7b1126..6088b44 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -632,6 +632,34 @@
</para>
</section>
+<section id='ref-classes-deprecated'>
+ <title><filename>deprecated.bbclass</filename></title>
+
+ <para>
+ The <filename>deprecated</filename> class identifies recipes
+ that for one reason or another are being considered for removal
+ from their current layer. It may be due to persistent, known
+ issues with the package, that there are newer, more feature-rich
+ alternatives available in the same layer or that the recipe is
+ no longer needed. The recipe should provide a reason for the
+ depercation and a suggestion to consumers of the recipe as to how
+ to proceed.
+ To use this class, inherit the class globally and set
+ <link linkend='var-PNDEPRECATED'><filename>PNDEPRECATED</filename></link>
+ for each recipe you intend to deprecate.
+ Specify the <link linkend='var-PN'><filename>PN</filename></link>
+ value as a variable flag (varflag) and provide a reason, which is
+ reported, if the package is requested to be built as the value.
+ For example, if you want to deprecate a recipe called "exoticware",
+ you add the following to your <filename>local.conf</filename>
+ or distribution configuration:
+ <literallayout class='monospaced'>
+ INHERIT += "deprecated"
+ PNDEPRECATED[exoticware] = "'exoticware' is considered obsolete and has been replaced by 'standardware'. 'exoticware' may not appear in future releases."
+ </literallayout>
+ </para>
+</section>
+
<section id='ref-classes-devshell'>
<title><filename>devshell.bbclass</filename></title>
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index f79cdd2..629d167 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -9920,6 +9920,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
</glossdef>
</glossentry>
+ <glossentry id='var-PNDEPRECATED'><glossterm>PNDEPRECATED</glossterm>
+ <info>
+ PNDEPRECATED[doc] = "Lists recipes that may be removed in a future release or have more actively maintained alternatives."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Lists recipes that may be removed in a future release or
+ have more actively maintained alternatives.
+ This variable works in conjunction with the
+ <link linkend='ref-classes-deprecated'><filename>deprecated</filename></link>
+ class, which the recipe must inherit globally.
+ </para>
+
+ <para>
+ To identify a recipe as deprecated, inherit the class
+ globally and use the variable in your
+ <filename>local.conf</filename> file.
+ Here is an example that will show a warning when
+ <filename>myrecipe</filename> is included in a project:
+ <literallayout class='monospaced'>
+ INHERIT += "deprecated"
+ PNDEPRECATED[myrecipe] = "Recipe is no longer actively maintained, you should consider using 'mynewrecipe' as an alternative."
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-POPULATE_SDK_POST_HOST_COMMAND'><glossterm>POPULATE_SDK_POST_HOST_COMMAND</glossterm>
<info>
POPULATE_SDK_POST_HOST_COMMAND[doc] = "Specifies a list of functions to call once the OpenEmbedded build system has created host part of the SDK."
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 0000000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+# PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+ deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+ if deprecated:
+ bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + str(d.getVar('MACHINE'
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
-INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
--
1.9.1
^ permalink raw reply related [flat|nested] 12+ messages in thread[parent not found: <20170227183329.9748.13885@do.openembedded.org>]
* Re: ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
[not found] ` <20170227183329.9748.13885@do.openembedded.org>
@ 2017-02-27 20:06 ` Joe MacDonald
2017-02-27 20:25 ` Leonardo Sandoval
0 siblings, 1 reply; 12+ messages in thread
From: Joe MacDonald @ 2017-02-27 20:06 UTC (permalink / raw)
To: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
[✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote:
> == Series Details ==
>
> Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
> Revision: 3
> URL : https://patchwork.openembedded.org/series/5489/
> State : failure
>
> == Summary ==
>
>
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
>
>
>
> * Issue Series does not apply on top of target branch [test_series_merge_on_head]
> Suggested fix Rebase your series on top of targeted branch
> Targeted branch master (currently at 65cfc8aca3)
I had been out of date, but this time I'm reasonably confident v3 is
still directly on top of master.
yocto-mainline> git config --local --get-regexp '^remote'
remote.yocto.url git://git.yoctoproject.org/poky
remote.yocto.projectname poky
remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/*
yocto-mainline> git pull
Already up-to-date.
yocto-mainline> git status
On branch master
Your branch is ahead of 'yocto/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working directory clean
Is patchtest having a bad day?
> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> Otherwise we would appreciate you correcting the issues and submitting a new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
>
> ---
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
>
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
2017-02-27 20:06 ` ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3) Joe MacDonald
@ 2017-02-27 20:25 ` Leonardo Sandoval
2017-02-27 22:24 ` Joe MacDonald
0 siblings, 1 reply; 12+ messages in thread
From: Leonardo Sandoval @ 2017-02-27 20:25 UTC (permalink / raw)
To: Joe MacDonald; +Cc: openembedded-core
On Mon, 2017-02-27 at 15:06 -0500, Joe MacDonald wrote:
> [✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote:
>
> > == Series Details ==
> >
> > Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
> > Revision: 3
> > URL : https://patchwork.openembedded.org/series/5489/
> > State : failure
> >
> > == Summary ==
> >
> >
> > Thank you for submitting this patch series to OpenEmbedded Core. This is
> > an automated response. Several tests have been executed on the proposed
> > series by patchtest resulting in the following failures:
> >
> >
> >
> > * Issue Series does not apply on top of target branch [test_series_merge_on_head]
> > Suggested fix Rebase your series on top of targeted branch
> > Targeted branch master (currently at 65cfc8aca3)
>
> I had been out of date, but this time I'm reasonably confident v3 is
> still directly on top of master.
>
> yocto-mainline> git config --local --get-regexp '^remote'
> remote.yocto.url git://git.yoctoproject.org/poky
> remote.yocto.projectname poky
> remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/*
> yocto-mainline> git pull
> Already up-to-date.
> yocto-mainline> git status
> On branch master
> Your branch is ahead of 'yocto/master' by 1 commit.
> (use "git push" to publish your local commits)
>
> nothing to commit, working directory clean
>
> Is patchtest having a bad day?
yes, there were some issues with the cron job running patchtest but
that is now solved. The problem is that your patch is a documentation
patch, not a oe-core patch, so it does not apply into oe-core. Send it
to the correct list (yocto@yoctoproject.org) if necessary.
>
> > If you believe any of these test results are incorrect, please reply to the
> > mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> > Otherwise we would appreciate you correcting the issues and submitting a new
> > version of the patchset if applicable. Please ensure you add/increment the
> > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> > [PATCH v3] -> ...).
> >
> > ---
> > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> >
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
2017-02-27 20:25 ` Leonardo Sandoval
@ 2017-02-27 22:24 ` Joe MacDonald
0 siblings, 0 replies; 12+ messages in thread
From: Joe MacDonald @ 2017-02-27 22:24 UTC (permalink / raw)
To: Leonardo Sandoval; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]
[Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)] On 17.02.27 (Mon 14:25) Leonardo Sandoval wrote:
> On Mon, 2017-02-27 at 15:06 -0500, Joe MacDonald wrote:
> > [✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote:
> >
> > > == Series Details ==
> > >
> > > Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
> > > Revision: 3
> > > URL : https://patchwork.openembedded.org/series/5489/
> > > State : failure
> > >
> > > == Summary ==
> > >
> > >
> > > Thank you for submitting this patch series to OpenEmbedded Core. This is
> > > an automated response. Several tests have been executed on the proposed
> > > series by patchtest resulting in the following failures:
> > >
> > >
> > >
> > > * Issue Series does not apply on top of target branch [test_series_merge_on_head]
> > > Suggested fix Rebase your series on top of targeted branch
> > > Targeted branch master (currently at 65cfc8aca3)
> >
> > I had been out of date, but this time I'm reasonably confident v3 is
> > still directly on top of master.
> >
> > yocto-mainline> git config --local --get-regexp '^remote'
> > remote.yocto.url git://git.yoctoproject.org/poky
> > remote.yocto.projectname poky
> > remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/*
> > yocto-mainline> git pull
> > Already up-to-date.
> > yocto-mainline> git status
> > On branch master
> > Your branch is ahead of 'yocto/master' by 1 commit.
> > (use "git push" to publish your local commits)
> >
> > nothing to commit, working directory clean
> >
> > Is patchtest having a bad day?
>
> yes, there were some issues with the cron job running patchtest but
> that is now solved. The problem is that your patch is a documentation
> patch, not a oe-core patch, so it does not apply into oe-core. Send it
> to the correct list (yocto@yoctoproject.org) if necessary.
It's actually both a change to oe-core and the accompanying
documentation. I wasn't aware that they needed to be sent to separate
lists when introducing a change to meta/ and documentation/ (to document
the change in meta/, obviously). Seems like an odd thing to do, but
I'll break them up into separate commits, I guess.
-J.
>
>
>
>
>
> >
> > > If you believe any of these test results are incorrect, please reply to the
> > > mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> > > Otherwise we would appreciate you correcting the issues and submitting a new
> > > version of the patchset if applicable. Please ensure you add/increment the
> > > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> > > [PATCH v3] -> ...).
> > >
> > > ---
> > > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> > > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> > >
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v4] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
2017-02-24 4:00 [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes Joe MacDonald
` (3 preceding siblings ...)
[not found] ` <20170227183329.9748.13885@do.openembedded.org>
@ 2017-03-03 13:57 ` Joe MacDonald
4 siblings, 0 replies; 12+ messages in thread
From: Joe MacDonald @ 2017-03-03 13:57 UTC (permalink / raw)
To: openembedded-core
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
---
Literally no different than v1, differs from v3 in that the doccumentation for
PNDEPRECATED has been removed again, since updates to documentation have to go
to a different list.
meta/classes/deprecated.bbclass | 16 ++++++++++++++++
meta/conf/distro/defaultsetup.conf | 3 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/deprecated.bbclass
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 0000000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+# PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+ deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+ if deprecated:
+ bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + str(d.getVar('MACHINE'
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
-INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
--
1.9.1
^ permalink raw reply related [flat|nested] 12+ messages in thread