Patchwork [CONSOLIDATED,PULL,14/16] distro-tracking: update data for some toolchain recipes

login
register
mail settings
Submitter Saul Wold
Date Oct. 19, 2011, 8:28 a.m.
Message ID <436a9b443962036ff35a5ffd86d80ad44350d5f2.1319012721.git.sgw@linux.intel.com>
Download mbox | patch
Permalink /patch/13515/
State New, archived
Headers show

Comments

Saul Wold - Oct. 19, 2011, 8:28 a.m.
From: Nitin A Kamble <nitin.a.kamble@intel.com>

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 .../conf/distro/include/distro_tracking_fields.inc |   42 ++++++++++++--------
 1 files changed, 25 insertions(+), 17 deletions(-)
Koen Kooi - Oct. 19, 2011, 8:30 a.m.
btrfs-tools is a toolchain recipe?!?!?!



Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:

> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
> .../conf/distro/include/distro_tracking_fields.inc |   42 ++++++++++++--------
> 1 files changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
> index abc2cbf..e68bbe1 100644
> --- a/meta/conf/distro/include/distro_tracking_fields.inc
> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all local code
> RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> -RECIPE_STATUS_pn-nasm="green" 
> +RECIPE_STATUS_pn-nasm="green"
> RECIPE_LATEST_VERSION_pn-nasm="2.07"
> -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011" 
> +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> +RECIPE_STATUS_pn-btrfs-tools="green"
> +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
> +
> RECIPE_STATUS_pn-perl="red" # upgrade needed
> RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> RECIPE_MAINTAINER_pn-prelink = "Mark Hatle <mark.hatle@windriver.com>"
> 
> -RECIPE_STATUS_pn-python-dbus="red" 
> -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> +RECIPE_STATUS_pn-python-dbus="green" 
> +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
> 
> @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
> 
> RECIPE_STATUS_pn-python-scons="green"
> -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
> +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
> +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
> DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
> RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
> RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
> RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> RECIPE_STATUS_pn-gnu-config="green" 
> -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
> +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
> DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
> RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
> -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011" 
> +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011" 
> RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> RECIPE_STATUS_pn-mpfr="green"
> -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
> -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011" 
> +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
> +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011" 
> +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
> RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> RECIPE_STATUS_pn-gmp="green"
> @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25, 2011"
> RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
> 
> -RECIPE_STATUS_pn-byacc="red" 
> +RECIPE_STATUS_pn-byacc="green" 
> RECIPE_LATEST_VERSION_pn-byacc="20101229"
> -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011" 
> +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011" 
> +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
> RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> RECIPE_STATUS_pn-libconvert-asn1-perl="green" 
> @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl = "Aug 13, 2010"
> RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> RECIPE_STATUS_pn-libxml-parser-perl="green" 
> -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
> -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
> +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
> +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
> RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> 
> RECIPE_STATUS_pn-cmake-native="green" 
> @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project maintained"
> RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011" 
> DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
> 
> -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
> -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
> -
> DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart <dvhart@linux.intel.com>"
> 
> -- 
> 1.7.6.2
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Nitin A Kamble - Oct. 19, 2011, 3:49 p.m.
Koen,
   Why do you ask ?

Nitin

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, October 19, 2011 1:31 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> update data for some toolchain recipes
> 
> btrfs-tools is a toolchain recipe?!?!?!
> 
> 
> 
> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
> 
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > ---
> > .../conf/distro/include/distro_tracking_fields.inc |   42
> ++++++++++++--------
> > 1 files changed, 25 insertions(+), 17 deletions(-)
> >
> > diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
> b/meta/conf/distro/include/distro_tracking_fields.inc
> > index abc2cbf..e68bbe1 100644
> > --- a/meta/conf/distro/include/distro_tracking_fields.inc
> > +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> > @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all
> local code
> > RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> > RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > -RECIPE_STATUS_pn-nasm="green"
> > +RECIPE_STATUS_pn-nasm="green"
> > RECIPE_LATEST_VERSION_pn-nasm="2.07"
> > -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> > RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > +RECIPE_STATUS_pn-btrfs-tools="green"
> > +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> > +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> > +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> progs"
> > +
> > RECIPE_STATUS_pn-perl="red" # upgrade needed
> > RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> > RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> > @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> > RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> > RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
> <mark.hatle@windriver.com>"
> >
> > -RECIPE_STATUS_pn-python-dbus="red"
> > -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> > -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> > +RECIPE_STATUS_pn-python-dbus="green"
> > +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> > +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
> dbus Mandriva=python-dbus"
> >
> > @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
> Kamble <nitin.a.kamble@intel.com>"
> > DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
> Ubuntu=python-pyrex"
> >
> > RECIPE_STATUS_pn-python-scons="green"
> > -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
> > +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
> > +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
> > DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons
> Ubuntu=scons Mandriva=scons Debian=scons"
> > RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
> > RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
> > RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-gnu-config="green"
> > -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
> > +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
> > DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
> > RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
> > -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-mpfr="green"
> > -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
> > -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
> > +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
> > +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
> > RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-gmp="green"
> > @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
> 2011"
> > RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
> >
> > -RECIPE_STATUS_pn-byacc="red"
> > +RECIPE_STATUS_pn-byacc="green"
> > RECIPE_LATEST_VERSION_pn-byacc="20101229"
> > -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
> > RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-libconvert-asn1-perl="green"
> > @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
> "Aug 13, 2010"
> > RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-libxml-parser-perl="green"
> > -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
> > -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
> > +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
> > +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> >
> > RECIPE_STATUS_pn-cmake-native="green"
> > @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
> maintained"
> > RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
> > DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
> >
> > -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> progs"
> > -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> <nitin.a.kamble@intel.com>"
> > -
> > DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> > RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
> <dvhart@linux.intel.com>"
> >
> > --
> > 1.7.6.2
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - Oct. 19, 2011, 3:52 p.m.
Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende geschreven:

> Koen,
>   Why do you ask ?

Because I want the commit message to match to commit and now it doesn't.

> 
> Nitin
> 
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Koen Kooi
>> Sent: Wednesday, October 19, 2011 1:31 AM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
>> update data for some toolchain recipes
>> 
>> btrfs-tools is a toolchain recipe?!?!?!
>> 
>> 
>> 
>> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
>> 
>>> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>>> 
>>> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>>> ---
>>> .../conf/distro/include/distro_tracking_fields.inc |   42
>> ++++++++++++--------
>>> 1 files changed, 25 insertions(+), 17 deletions(-)
>>> 
>>> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
>> b/meta/conf/distro/include/distro_tracking_fields.inc
>>> index abc2cbf..e68bbe1 100644
>>> --- a/meta/conf/distro/include/distro_tracking_fields.inc
>>> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
>>> @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all
>> local code
>>> RECIPE_LATEST_VERSION_pn-postinsts="1.0"
>>> RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> -RECIPE_STATUS_pn-nasm="green"
>>> +RECIPE_STATUS_pn-nasm="green"
>>> RECIPE_LATEST_VERSION_pn-nasm="2.07"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
>>> RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> +RECIPE_STATUS_pn-btrfs-tools="green"
>>> +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
>>> +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
>> progs"
>>> +
>>> RECIPE_STATUS_pn-perl="red" # upgrade needed
>>> RECIPE_LATEST_VERSION_pn-perl="5.12.1"
>>> RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
>>> @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
>> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
>>> RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
>>> RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
>> <mark.hatle@windriver.com>"
>>> 
>>> -RECIPE_STATUS_pn-python-dbus="red"
>>> -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
>>> -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
>>> +RECIPE_STATUS_pn-python-dbus="green"
>>> +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
>>> +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
>>> RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
>> dbus Mandriva=python-dbus"
>>> 
>>> @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
>> Kamble <nitin.a.kamble@intel.com>"
>>> DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
>> Ubuntu=python-pyrex"
>>> 
>>> RECIPE_STATUS_pn-python-scons="green"
>>> -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
>>> +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
>>> +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
>>> DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons
>> Ubuntu=scons Mandriva=scons Debian=scons"
>>> RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
>>> RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
>>> RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> RECIPE_STATUS_pn-gnu-config="green"
>>> -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
>>> +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
>>> DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
>>> RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
>>> RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> RECIPE_STATUS_pn-mpfr="green"
>>> -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
>>> +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
>>> RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> RECIPE_STATUS_pn-gmp="green"
>>> @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
>> 2011"
>>> RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
>>> 
>>> -RECIPE_STATUS_pn-byacc="red"
>>> +RECIPE_STATUS_pn-byacc="green"
>>> RECIPE_LATEST_VERSION_pn-byacc="20101229"
>>> -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
>>> +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
>>> RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> RECIPE_STATUS_pn-libconvert-asn1-perl="green"
>>> @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
>> "Aug 13, 2010"
>>> RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> RECIPE_STATUS_pn-libxml-parser-perl="green"
>>> -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
>>> -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
>>> +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
>>> +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
>>> RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> 
>>> RECIPE_STATUS_pn-cmake-native="green"
>>> @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
>> maintained"
>>> RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
>>> DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
>>> 
>>> -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
>> progs"
>>> -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
>> <nitin.a.kamble@intel.com>"
>>> -
>>> DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
>>> RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
>> <dvhart@linux.intel.com>"
>>> 
>>> --
>>> 1.7.6.2
>>> 
>>> 
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>> 
>> 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Nitin A Kamble - Oct. 19, 2011, 4:24 p.m.
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, October 19, 2011 8:52 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> update data for some toolchain recipes
> 
> 
> Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende
> geschreven:
> 
> > Koen,
> >   Why do you ask ?
> 
> Because I want the commit message to match to commit and now it
> doesn't.
> 
It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?

Nitin

> >
> > Nitin
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> >> Koen Kooi
> >> Sent: Wednesday, October 19, 2011 1:31 AM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> >> update data for some toolchain recipes
> >>
> >> btrfs-tools is a toolchain recipe?!?!?!
> >>
> >>
> >>
> >> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
> >>
> >>> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>>
> >>> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>> ---
> >>> .../conf/distro/include/distro_tracking_fields.inc |   42
> >> ++++++++++++--------
> >>> 1 files changed, 25 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
> >> b/meta/conf/distro/include/distro_tracking_fields.inc
> >>> index abc2cbf..e68bbe1 100644
> >>> --- a/meta/conf/distro/include/distro_tracking_fields.inc
> >>> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> >>> @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" #
> all
> >> local code
> >>> RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> >>> RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> -RECIPE_STATUS_pn-nasm="green"
> >>> +RECIPE_STATUS_pn-nasm="green"
> >>> RECIPE_LATEST_VERSION_pn-nasm="2.07"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> >>> RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> +RECIPE_STATUS_pn-btrfs-tools="green"
> >>> +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> >>> +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> >> progs"
> >>> +
> >>> RECIPE_STATUS_pn-perl="red" # upgrade needed
> >>> RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> >>> RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> >>> @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
> >> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> >>> RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> >>> RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
> >> <mark.hatle@windriver.com>"
> >>>
> >>> -RECIPE_STATUS_pn-python-dbus="red"
> >>> -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> >>> -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> >>> +RECIPE_STATUS_pn-python-dbus="green"
> >>> +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> >>> +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> >>> RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
> >> dbus Mandriva=python-dbus"
> >>>
> >>> @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
> >> Kamble <nitin.a.kamble@intel.com>"
> >>> DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
> >> Ubuntu=python-pyrex"
> >>>
> >>> RECIPE_STATUS_pn-python-scons="green"
> >>> -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
> >>> +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
> >>> +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
> >>> DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons
> >> Ubuntu=scons Mandriva=scons Debian=scons"
> >>> RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
> >>> RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-
> unifdef="2.6.18+git"
> >>> RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-gnu-config="green"
> >>> -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
> >>> +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
> >>> DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
> >>> RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
> >>> RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-mpfr="green"
> >>> -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
> >>> +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
> >>> RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-gmp="green"
> >>> @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan
> 25,
> >> 2011"
> >>> RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
> >>>
> >>> -RECIPE_STATUS_pn-byacc="red"
> >>> +RECIPE_STATUS_pn-byacc="green"
> >>> RECIPE_LATEST_VERSION_pn-byacc="20101229"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
> >>> RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-libconvert-asn1-perl="green"
> >>> @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
> >> "Aug 13, 2010"
> >>> RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-libxml-parser-perl="green"
> >>> -RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
> >>> -RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
> >>> +RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
> >>> +RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
> >>> RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>>
> >>> RECIPE_STATUS_pn-cmake-native="green"
> >>> @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = "Yocto Project
> >> maintained"
> >>> RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011"
> >>> DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
> >>>
> >>> -DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> >> progs"
> >>> -RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> >> <nitin.a.kamble@intel.com>"
> >>> -
> >>> DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> >>> RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart
> >> <dvhart@linux.intel.com>"
> >>>
> >>> --
> >>> 1.7.6.2
> >>>
> >>>
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - Oct. 19, 2011, 4:37 p.m.
Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:

> 
> 
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Koen Kooi
>> Sent: Wednesday, October 19, 2011 8:52 AM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
>> update data for some toolchain recipes
>> 
>> 
>> Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende
>> geschreven:
>> 
>>> Koen,
>>>  Why do you ask ?
>> 
>> Because I want the commit message to match to commit and now it
>> doesn't.
>> 
> It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?

Or per group, but saying "some toolchain recipes" is way too vague.
Phil Blundell - Oct. 19, 2011, 4:49 p.m.
On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
> > It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?
> 
> Or per group, but saying "some toolchain recipes" is way too vague.

Why do we have this distro tracking data in oe-core git anyway?  I'm not
entirely clear on what it's used by.

p.
Saul Wold - Oct. 19, 2011, 4:57 p.m.
On 10/19/2011 09:49 AM, Phil Blundell wrote:
> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
>>> It will be too many recipes to list on one line, shall I split the commit into multiple one for each recipe whose data is changed?
>>
>> Or per group, but saying "some toolchain recipes" is way too vague.
>
> Why do we have this distro tracking data in oe-core git anyway?  I'm not
> entirely clear on what it's used by.
>
Phil:

It's used by the tools that build http://packages.yoctoproject.org and 
to help recipe manage maintainer-ship and track what needs updating.

Many upstreams we can't track if updates are required automagically, so 
we need a place to record when the last manual check was, also possible 
reasons why we should not update to newer versions, ...

Sau!


> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Khem Raj - Oct. 19, 2011, 5 p.m.
On Wed, Oct 19, 2011 at 9:57 AM, Saul Wold <saul.wold@intel.com> wrote:
> On 10/19/2011 09:49 AM, Phil Blundell wrote:
>>
>> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>>>
>>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
>>>>
>>>> It will be too many recipes to list on one line, shall I split the
>>>> commit into multiple one for each recipe whose data is changed?
>>>
>>> Or per group, but saying "some toolchain recipes" is way too vague.
>>
>> Why do we have this distro tracking data in oe-core git anyway?  I'm not
>> entirely clear on what it's used by.
>>
> Phil:
>
> It's used by the tools that build http://packages.yoctoproject.org and to
> help recipe manage maintainer-ship and track what needs updating.

This could be managed via meta-data in packages I believe all that
information is there.

>
> Many upstreams we can't track if updates are required automagically, so we
> need a place to record when the last manual check was, also possible reasons
> why we should not update to newer versions, ...
>
> Sau!
>
>
>> p.
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Saul Wold - Oct. 19, 2011, 5:45 p.m.
On 10/19/2011 10:00 AM, Khem Raj wrote:
> On Wed, Oct 19, 2011 at 9:57 AM, Saul Wold<saul.wold@intel.com>  wrote:
>> On 10/19/2011 09:49 AM, Phil Blundell wrote:
>>>
>>> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>>>>
>>>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven:
>>>>>
>>>>> It will be too many recipes to list on one line, shall I split the
>>>>> commit into multiple one for each recipe whose data is changed?
>>>>
>>>> Or per group, but saying "some toolchain recipes" is way too vague.
>>>
>>> Why do we have this distro tracking data in oe-core git anyway?  I'm not
>>> entirely clear on what it's used by.
>>>
>> Phil:
>>
>> It's used by the tools that build http://packages.yoctoproject.org and to
>> help recipe manage maintainer-ship and track what needs updating.
>
> This could be managed via meta-data in packages I believe all that
> information is there.
>
Khem,

I am not quite following, are you suggesting incorporating the 
distro_tracking_fields info into the final packages (this word is 
overloaded sometimes), or adding it the recipe bb files?

If adding it to the recipe bb files, this was discussed and deemed 
inappropriate, as it's too dynamic and would clutter the recipe.

Sau!
>>
>> Many upstreams we can't track if updates are required automagically, so we
>> need a place to record when the last manual check was, also possible reasons
>> why we should not update to newer versions, ...
>>
>> Sau!
>>
>>
>>> p.
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - Oct. 19, 2011, 6:30 p.m.
On Wed, Oct 19, 2011 at 10:45 AM, Saul Wold <saul.wold@intel.com> wrote:
> On 10/19/2011 10:00 AM, Khem Raj wrote:
>>
>> On Wed, Oct 19, 2011 at 9:57 AM, Saul Wold<saul.wold@intel.com>  wrote:
>>>
>>> On 10/19/2011 09:49 AM, Phil Blundell wrote:
>>>>
>>>> On Wed, 2011-10-19 at 18:37 +0200, Koen Kooi wrote:
>>>>>
>>>>> Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende
>>>>> geschreven:
>>>>>>
>>>>>> It will be too many recipes to list on one line, shall I split the
>>>>>> commit into multiple one for each recipe whose data is changed?
>>>>>
>>>>> Or per group, but saying "some toolchain recipes" is way too vague.
>>>>
>>>> Why do we have this distro tracking data in oe-core git anyway?  I'm not
>>>> entirely clear on what it's used by.
>>>>
>>> Phil:
>>>
>>> It's used by the tools that build http://packages.yoctoproject.org and to
>>> help recipe manage maintainer-ship and track what needs updating.
>>
>> This could be managed via meta-data in packages I believe all that
>> information is there.
>>
> Khem,
>
> I am not quite following, are you suggesting incorporating the
> distro_tracking_fields info into the final packages (this word is overloaded
> sometimes), or adding it the recipe bb files?

I think this information is better generated at build time. Since that
will be accurate and the meta data can be

>
> If adding it to the recipe bb files, this was discussed and deemed
> inappropriate, as it's too dynamic and would clutter the recipe.

is it more dynamic than making any other change to the recipe ?
in other words are there chances that you just need to change the
recipe to mark this information.

>
> Sau!
>>>
>>> Many upstreams we can't track if updates are required automagically, so
>>> we
>>> need a place to record when the last manual check was, also possible
>>> reasons
>>> why we should not update to newer versions, ...

hmm manual check means it has to be done manually is there any thing
that needs it ?

I think unless they are distro specific which seems not since they are
in oe-core
they could exist in recipes  thats my opinion.

>>>
>>> Sau!
>>>
>>>
>>>> p.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
Otavio Salvador - Oct. 19, 2011, 7 p.m.
On Wed, Oct 19, 2011 at 16:30, Khem Raj <raj.khem@gmail.com> wrote:
...
>>>> Many upstreams we can't track if updates are required automagically, so
>>>> we
>>>> need a place to record when the last manual check was, also possible
>>>> reasons
>>>> why we should not update to newer versions, ...
>
> hmm manual check means it has to be done manually is there any thing
> that needs it ?
>
> I think unless they are distro specific which seems not since they are
> in oe-core
> they could exist in recipes  thats my opinion.

I agree that this should be put into the recipes. Besides this allows
for checking if it was updated when the version has been updated.

If done right, when updating the version this data will be updated
together. I see no change in the amount of changes.

A plus of this choice is it will be more difficult to forget to update
that info. This happened in last qt update for an example.
Saul Wold - Oct. 19, 2011, 11:33 p.m.
On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
> ...
>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>> we
>>>>> need a place to record when the last manual check was, also possible
>>>>> reasons
>>>>> why we should not update to newer versions, ...
>>
>> hmm manual check means it has to be done manually is there any thing
>> that needs it ?
>>
>> I think unless they are distro specific which seems not since they are
>> in oe-core
>> they could exist in recipes  thats my opinion.
>
> I agree that this should be put into the recipes. Besides this allows
> for checking if it was updated when the version has been updated.
>
> If done right, when updating the version this data will be updated
> together. I see no change in the amount of changes.
>
> A plus of this choice is it will be more difficult to forget to update
> that info. This happened in last qt update for an example.
>

This may need to be something that the TSC brings up, possibly we can 
talk about it in Prague next week.

Sau!
Richard Purdie - Oct. 20, 2011, 2:25 p.m.
On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
> > ...
> >>>>> Many upstreams we can't track if updates are required automagically, so
> >>>>> we
> >>>>> need a place to record when the last manual check was, also possible
> >>>>> reasons
> >>>>> why we should not update to newer versions, ...
> >>
> >> hmm manual check means it has to be done manually is there any thing
> >> that needs it ?
> >>
> >> I think unless they are distro specific which seems not since they are
> >> in oe-core
> >> they could exist in recipes  thats my opinion.
> >
> > I agree that this should be put into the recipes. Besides this allows
> > for checking if it was updated when the version has been updated.
> >
> > If done right, when updating the version this data will be updated
> > together. I see no change in the amount of changes.
> >
> > A plus of this choice is it will be more difficult to forget to update
> > that info. This happened in last qt update for an example.
> >
> 
> This may need to be something that the TSC brings up, possibly we can 
> talk about it in Prague next week.

So just to give some background here, the information in those files was
added by Yocto people to give some idea of the update status of various
recipes. This included when the version was last checked/updated for
recipes which we can't automate that process for, when certain cleanup
checks were made, what the general state of the recipe was and who on
the Yocto team was specifically looking after given recipes.

When it was discussed, some of it was Yocto specific, some of it wasn't
and popular opinion was against it going into the recipes themselves. I
was ok with that given we have the pn- overrides and can handle the
problem that way just fine.

OE-Core happened and we kept the data with OE-Core at least for now. We
have several options:

a) Keep the data where it is
b) Merge the data into the recipes
c) Move the data out of OE-Core

Since a lot of that data is fairly Yocto process specific, it may make
sense to move it over to meta-yocto...

Cheers,

Richard
Martin Jansa - Oct. 20, 2011, 2:36 p.m.
On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
> > > ...
> > >>>>> Many upstreams we can't track if updates are required automagically, so
> > >>>>> we
> > >>>>> need a place to record when the last manual check was, also possible
> > >>>>> reasons
> > >>>>> why we should not update to newer versions, ...
> > >>
> > >> hmm manual check means it has to be done manually is there any thing
> > >> that needs it ?
> > >>
> > >> I think unless they are distro specific which seems not since they are
> > >> in oe-core
> > >> they could exist in recipes  thats my opinion.
> > >
> > > I agree that this should be put into the recipes. Besides this allows
> > > for checking if it was updated when the version has been updated.
> > >
> > > If done right, when updating the version this data will be updated
> > > together. I see no change in the amount of changes.
> > >
> > > A plus of this choice is it will be more difficult to forget to update
> > > that info. This happened in last qt update for an example.
> > >
> > 
> > This may need to be something that the TSC brings up, possibly we can 
> > talk about it in Prague next week.
> 
> So just to give some background here, the information in those files was
> added by Yocto people to give some idea of the update status of various
> recipes. This included when the version was last checked/updated for
> recipes which we can't automate that process for, when certain cleanup
> checks were made, what the general state of the recipe was and who on
> the Yocto team was specifically looking after given recipes.
> 
> When it was discussed, some of it was Yocto specific, some of it wasn't
> and popular opinion was against it going into the recipes themselves. I
> was ok with that given we have the pn- overrides and can handle the
> problem that way just fine.
> 
> OE-Core happened and we kept the data with OE-Core at least for now. We
> have several options:
> 
> a) Keep the data where it is
> b) Merge the data into the recipes
> c) Move the data out of OE-Core
> 
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...

I don't like "global" files where many people should maintain their info
and it's so easy to forgot when it's somewhere else then real changes
(like it was with checksums.ini and sane-src*.ini).

So I vote for b) Merge the data into the recipes, only problem with this
is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
we should and move at least DESCRIPTION and similar variables too.

c) moving it to meta-yocto will probably make distro-tracking info even
more outdated as sometimes different people then who did upgrade in
oe-core will have to update distro-tracking info in this layer (this is
also the case now sometimes, but with distro-tracking info in recipe we
can try better to update it with upgrades).

Regards,
Koen Kooi - Oct. 20, 2011, 2:48 p.m.
Op 20 okt. 2011, om 16:36 heeft Martin Jansa het volgende geschreven:

> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
>>>> ...
>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>> we
>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>> reasons
>>>>>>>> why we should not update to newer versions, ...
>>>>> 
>>>>> hmm manual check means it has to be done manually is there any thing
>>>>> that needs it ?
>>>>> 
>>>>> I think unless they are distro specific which seems not since they are
>>>>> in oe-core
>>>>> they could exist in recipes  thats my opinion.
>>>> 
>>>> I agree that this should be put into the recipes. Besides this allows
>>>> for checking if it was updated when the version has been updated.
>>>> 
>>>> If done right, when updating the version this data will be updated
>>>> together. I see no change in the amount of changes.
>>>> 
>>>> A plus of this choice is it will be more difficult to forget to update
>>>> that info. This happened in last qt update for an example.
>>>> 
>>> 
>>> This may need to be something that the TSC brings up, possibly we can 
>>> talk about it in Prague next week.
>> 
>> So just to give some background here, the information in those files was
>> added by Yocto people to give some idea of the update status of various
>> recipes. This included when the version was last checked/updated for
>> recipes which we can't automate that process for, when certain cleanup
>> checks were made, what the general state of the recipe was and who on
>> the Yocto team was specifically looking after given recipes.
>> 
>> When it was discussed, some of it was Yocto specific, some of it wasn't
>> and popular opinion was against it going into the recipes themselves. I
>> was ok with that given we have the pn- overrides and can handle the
>> problem that way just fine.
>> 
>> OE-Core happened and we kept the data with OE-Core at least for now. We
>> have several options:
>> 
>> a) Keep the data where it is
>> b) Merge the data into the recipes
>> c) Move the data out of OE-Core
>> 
>> Since a lot of that data is fairly Yocto process specific, it may make
>> sense to move it over to meta-yocto...
> 
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).
> 
> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
> 
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).

I agree completely with Martin.

regards,

Koen
Richard Purdie - Oct. 20, 2011, 3:55 p.m.
On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> > On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
> > > > ...
> > > >>>>> Many upstreams we can't track if updates are required automagically, so
> > > >>>>> we
> > > >>>>> need a place to record when the last manual check was, also possible
> > > >>>>> reasons
> > > >>>>> why we should not update to newer versions, ...
> > > >>
> > > >> hmm manual check means it has to be done manually is there any thing
> > > >> that needs it ?
> > > >>
> > > >> I think unless they are distro specific which seems not since they are
> > > >> in oe-core
> > > >> they could exist in recipes  thats my opinion.
> > > >
> > > > I agree that this should be put into the recipes. Besides this allows
> > > > for checking if it was updated when the version has been updated.
> > > >
> > > > If done right, when updating the version this data will be updated
> > > > together. I see no change in the amount of changes.
> > > >
> > > > A plus of this choice is it will be more difficult to forget to update
> > > > that info. This happened in last qt update for an example.
> > > >
> > > 
> > > This may need to be something that the TSC brings up, possibly we can 
> > > talk about it in Prague next week.
> > 
> > So just to give some background here, the information in those files was
> > added by Yocto people to give some idea of the update status of various
> > recipes. This included when the version was last checked/updated for
> > recipes which we can't automate that process for, when certain cleanup
> > checks were made, what the general state of the recipe was and who on
> > the Yocto team was specifically looking after given recipes.
> > 
> > When it was discussed, some of it was Yocto specific, some of it wasn't
> > and popular opinion was against it going into the recipes themselves. I
> > was ok with that given we have the pn- overrides and can handle the
> > problem that way just fine.
> > 
> > OE-Core happened and we kept the data with OE-Core at least for now. We
> > have several options:
> > 
> > a) Keep the data where it is
> > b) Merge the data into the recipes
> > c) Move the data out of OE-Core
> > 
> > Since a lot of that data is fairly Yocto process specific, it may make
> > sense to move it over to meta-yocto...
> 
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).

Some data does make sense to be maintained globally and I don't think we
should automatically say its bad. It depends what the use case is and
how its intended to be used.

> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
> 
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).

I'd actually like Saul's view on this since he generally looks after
that data. There as been discussion about whether it is "internal" yocto
tracking stuff or whether its more general OE focused and I don't know
what the answer is there. I think there is a mixture of uses. I'm also
wary of "pushing" Yocto policy into OE which I think this might amount
to.

As a specific example, we've moved away from wanting MAINTAINER info in
the recipes in the past and this gets us back there again. I don't
really want to loop over adding data and then removing it again
repeatedly so this needs thought/discussion. Who gets their name in the
MAINTAINER field exactly? What is the process for that and what
responsibilities does that person have?

Cheers,

Richard
Eric BENARD - Oct. 20, 2011, 4:02 p.m.
Hi,

Le 19/10/2011 21:00, Otavio Salvador a écrit :
> A plus of this choice is it will be more difficult to forget to update
> that info. This happened in last qt update for an example.
>
in fact that was in the first patch submitted but got lost in the v2 :-(

Eric
Khem Raj - Oct. 20, 2011, 4:18 p.m.
On Thu, Oct 20, 2011 at 7:25 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> a) Keep the data where it is
> b) Merge the data into the recipes

We once had maintainers and then backed out of it
this would reintroduce that and bitbake might have
to eat more memory to parse this information.

> c) Move the data out of OE-Core

For now this would be a better solution IMO

>
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...
>

Yes it seems to be apt.
Koen Kooi - Oct. 20, 2011, 4:24 p.m.
Op 20 okt. 2011, om 17:55 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
>> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
>>>>> ...
>>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>>> we
>>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>>> reasons
>>>>>>>>> why we should not update to newer versions, ...
>>>>>> 
>>>>>> hmm manual check means it has to be done manually is there any thing
>>>>>> that needs it ?
>>>>>> 
>>>>>> I think unless they are distro specific which seems not since they are
>>>>>> in oe-core
>>>>>> they could exist in recipes  thats my opinion.
>>>>> 
>>>>> I agree that this should be put into the recipes. Besides this allows
>>>>> for checking if it was updated when the version has been updated.
>>>>> 
>>>>> If done right, when updating the version this data will be updated
>>>>> together. I see no change in the amount of changes.
>>>>> 
>>>>> A plus of this choice is it will be more difficult to forget to update
>>>>> that info. This happened in last qt update for an example.
>>>>> 
>>>> 
>>>> This may need to be something that the TSC brings up, possibly we can 
>>>> talk about it in Prague next week.
>>> 
>>> So just to give some background here, the information in those files was
>>> added by Yocto people to give some idea of the update status of various
>>> recipes. This included when the version was last checked/updated for
>>> recipes which we can't automate that process for, when certain cleanup
>>> checks were made, what the general state of the recipe was and who on
>>> the Yocto team was specifically looking after given recipes.
>>> 
>>> When it was discussed, some of it was Yocto specific, some of it wasn't
>>> and popular opinion was against it going into the recipes themselves. I
>>> was ok with that given we have the pn- overrides and can handle the
>>> problem that way just fine.
>>> 
>>> OE-Core happened and we kept the data with OE-Core at least for now. We
>>> have several options:
>>> 
>>> a) Keep the data where it is
>>> b) Merge the data into the recipes
>>> c) Move the data out of OE-Core
>>> 
>>> Since a lot of that data is fairly Yocto process specific, it may make
>>> sense to move it over to meta-yocto...
>> 
>> I don't like "global" files where many people should maintain their info
>> and it's so easy to forgot when it's somewhere else then real changes
>> (like it was with checksums.ini and sane-src*.ini).
> 
> Some data does make sense to be maintained globally and I don't think we
> should automatically say its bad. It depends what the use case is and
> how its intended to be used.
> 
>> So I vote for b) Merge the data into the recipes, only problem with this
>> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
>> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
>> we should and move at least DESCRIPTION and similar variables too.
>> 
>> c) moving it to meta-yocto will probably make distro-tracking info even
>> more outdated as sometimes different people then who did upgrade in
>> oe-core will have to update distro-tracking info in this layer (this is
>> also the case now sometimes, but with distro-tracking info in recipe we
>> can try better to update it with upgrades).
> 
> I'd actually like Saul's view on this since he generally looks after
> that data. There as been discussion about whether it is "internal" yocto
> tracking stuff or whether its more general OE focused and I don't know
> what the answer is there. I think there is a mixture of uses. I'm also
> wary of "pushing" Yocto policy into OE which I think this might amount
> to.
> 
> As a specific example, we've moved away from wanting MAINTAINER info in
> the recipes in the past and this gets us back there again. I don't
> really want to loop over adding data and then removing it again
> repeatedly so this needs thought/discussion. Who gets their name in the
> MAINTAINER field exactly? What is the process for that and what
> responsibilities does that person have?

The problem wasn't with MAINTAINER being in the recipe, the problem was MAINTAINER ending up in the ipk data. The 'abiword crashes' bugs we had years ago illustrated the problem clearly. Abiword only crashed if you used code sourcery binutils, but not with stock binutils. Graeme couldn't get the message thru that he was indeed maintaining abi in OE but wasn't responsible for people using broken toolchains. The specific abiword issue was resolved when the distro in question stopped using CSL stuff (familiar or angstrom, I forget).

I'm in favour of having info in the recipe (or bbappend!) who is looking after it if it doesn't end up in the output package. 

Regardless of where to put the info, I would like to propose to orphan every recipe in OE-core and ask for volunteers. There's a ton of stuff I want to look after (bluez, gstreamer, pulse, avahi, X) which already has a maintainer from its yocto/poky/whatever legacy, but I feel is not being looked after with much attention. And adding to the problem is that most yocto people aren't using OE-core, but poky.

regards,

Koen
Joshua Lock - Oct. 20, 2011, 5:38 p.m.
On 10/20/2011 09:24 AM, Koen Kooi wrote:>
> I'm in favour of having info in the recipe (or bbappend!) who is looking after it if it doesn't end up in the output package. 
> 
> Regardless of where to put the info, I would like to propose to orphan every recipe in OE-core and ask for volunteers. There's a ton of stuff I want to look after (bluez, gstreamer, pulse, avahi, X) which already has a maintainer from its yocto/poky/whatever legacy, but I feel is not being looked after with much attention. And adding to the problem is that most yocto people aren't using OE-core, but poky.

I feel the need to point out that you don't have to be the named
maintainer to submit a patch.

Personally I'd be happy to see maintainer ship go to other members of
the community.
I think a better approach would be to seek volunteers before we orphan
things? That way things which don't receive volunteers can stay with the
current maintainer?

Cheers,
Joshua
Saul Wold - Oct. 20, 2011, 9:28 p.m.
On 10/20/2011 08:55 AM, Richard Purdie wrote:
> On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
>> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>   wrote:
>>>>> ...
>>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>>> we
>>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>>> reasons
>>>>>>>>> why we should not update to newer versions, ...
>>>>>>
>>>>>> hmm manual check means it has to be done manually is there any thing
>>>>>> that needs it ?
>>>>>>
>>>>>> I think unless they are distro specific which seems not since they are
>>>>>> in oe-core
>>>>>> they could exist in recipes  thats my opinion.
>>>>>
>>>>> I agree that this should be put into the recipes. Besides this allows
>>>>> for checking if it was updated when the version has been updated.
>>>>>
>>>>> If done right, when updating the version this data will be updated
>>>>> together. I see no change in the amount of changes.
>>>>>
>>>>> A plus of this choice is it will be more difficult to forget to update
>>>>> that info. This happened in last qt update for an example.
>>>>>
>>>>
>>>> This may need to be something that the TSC brings up, possibly we can
>>>> talk about it in Prague next week.
>>>
>>> So just to give some background here, the information in those files was
>>> added by Yocto people to give some idea of the update status of various
>>> recipes. This included when the version was last checked/updated for
>>> recipes which we can't automate that process for, when certain cleanup
>>> checks were made, what the general state of the recipe was and who on
>>> the Yocto team was specifically looking after given recipes.
>>>
>>> When it was discussed, some of it was Yocto specific, some of it wasn't
>>> and popular opinion was against it going into the recipes themselves. I
>>> was ok with that given we have the pn- overrides and can handle the
>>> problem that way just fine.
>>>
>>> OE-Core happened and we kept the data with OE-Core at least for now. We
>>> have several options:
>>>
>>> a) Keep the data where it is
>>> b) Merge the data into the recipes
>>> c) Move the data out of OE-Core
>>>
>>> Since a lot of that data is fairly Yocto process specific, it may make
>>> sense to move it over to meta-yocto...
>>
>> I don't like "global" files where many people should maintain their info
>> and it's so easy to forgot when it's somewhere else then real changes
>> (like it was with checksums.ini and sane-src*.ini).
>
> Some data does make sense to be maintained globally and I don't think we
> should automatically say its bad. It depends what the use case is and
> how its intended to be used.
>
>> So I vote for b) Merge the data into the recipes, only problem with this
>> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
>> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
>> we should and move at least DESCRIPTION and similar variables too.
>>
>> c) moving it to meta-yocto will probably make distro-tracking info even
>> more outdated as sometimes different people then who did upgrade in
>> oe-core will have to update distro-tracking info in this layer (this is
>> also the case now sometimes, but with distro-tracking info in recipe we
>> can try better to update it with upgrades).
>
> I'd actually like Saul's view on this since he generally looks after
> that data. There as been discussion about whether it is "internal" yocto
> tracking stuff or whether its more general OE focused and I don't know
> what the answer is there. I think there is a mixture of uses. I'm also
> wary of "pushing" Yocto policy into OE which I think this might amount
> to.
>
> As a specific example, we've moved away from wanting MAINTAINER info in
> the recipes in the past and this gets us back there again. I don't
> really want to loop over adding data and then removing it again
> repeatedly so this needs thought/discussion. Who gets their name in the
> MAINTAINER field exactly? What is the process for that and what
> responsibilities does that person have?
>
I am working on a proposal that will be a mix of the above, move some of 
the Version tracking and Updating information into the recipes and keep 
the large distro tracking file, but move it to meta-yocto.

It's clear based on these emails (and the following ones), that there 
has been some history with maintainer-ship of the recipes, so we need to 
generate some policy and process around this.  As Josh already noted, 
this is a community project there for a having updates and input from 
the community is important.

Part of our original purpose of putting people's names in the 
distro_tracking_fields was to have those people do the updates, interact 
with the upstream community and work to address any issues with the 
recipes they where marked for.  This was all a starting point.

I plan to have a proposal by next week that will address the current 
distro_tracking_fields.inc file, I do not think I am going to tackle the 
maintainer-ship issue at this point, that will be the next steps.

I, of course, welcome people's constructive feedback

Thanks
	Sau!

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

Patch

diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
index abc2cbf..e68bbe1 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -3005,11 +3005,19 @@  RECIPE_STATUS_pn-run-postinsts="green" # all local code
 RECIPE_LATEST_VERSION_pn-postinsts="1.0"
 RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
-RECIPE_STATUS_pn-nasm="green" 
+RECIPE_STATUS_pn-nasm="green"
 RECIPE_LATEST_VERSION_pn-nasm="2.07"
-RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011" 
+RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
+RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
 RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
+RECIPE_STATUS_pn-btrfs-tools="green"
+RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
+RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
+RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
+RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
+DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
+
 RECIPE_STATUS_pn-perl="red" # upgrade needed
 RECIPE_LATEST_VERSION_pn-perl="5.12.1"
 RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
@@ -3020,9 +3028,9 @@  RECIPE_LATEST_VERSION_pn-prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
 RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
 RECIPE_MAINTAINER_pn-prelink = "Mark Hatle <mark.hatle@windriver.com>"
 
-RECIPE_STATUS_pn-python-dbus="red" 
-RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
-RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
+RECIPE_STATUS_pn-python-dbus="green" 
+RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
+RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
 RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
 
@@ -3062,7 +3070,8 @@  RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
 
 RECIPE_STATUS_pn-python-scons="green"
-RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
+RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
+RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
 DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
 RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
 RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble <nitin.a.kamble@intel.com>"
@@ -3087,15 +3096,16 @@  RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
 RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
 RECIPE_STATUS_pn-gnu-config="green" 
-RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
+RECIPE_LATEST_VERSION_pn-gnu-config="svn"
 DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
 RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
-RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011" 
+RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011" 
 RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
 RECIPE_STATUS_pn-mpfr="green"
-RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
-RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011" 
+RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
+RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011" 
+RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
 RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
 RECIPE_STATUS_pn-gmp="green"
@@ -3110,9 +3120,10 @@  RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25, 2011"
 RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
 
-RECIPE_STATUS_pn-byacc="red" 
+RECIPE_STATUS_pn-byacc="green" 
 RECIPE_LATEST_VERSION_pn-byacc="20101229"
-RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011" 
+RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011" 
+RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
 RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
 RECIPE_STATUS_pn-libconvert-asn1-perl="green" 
@@ -3122,8 +3133,8 @@  RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl = "Aug 13, 2010"
 RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
 RECIPE_STATUS_pn-libxml-parser-perl="green" 
-RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.36"
-RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Nov 18, 2009"
+RECIPE_LATEST_VERSION_pn-libxml-parser-perl="2.41"
+RECIPE_LAST_UPDATE_pn-libxml-parser-perl = "Oct 18, 2011"
 RECIPE_MAINTAINER_pn-libxml-parser-perl = "Nitin A Kamble <nitin.a.kamble@intel.com>"
 
 RECIPE_STATUS_pn-cmake-native="green" 
@@ -5922,9 +5933,6 @@  RECIPE_COMMENTS_pn-pseudo = "Yocto Project maintained"
 RECIPE_MANUAL_CHECK_DATE_pn-pseudo = "Jun 06, 2011" 
 DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
 
-DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
-RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble <nitin.a.kamble@intel.com>"
-
 DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
 RECIPE_MAINTAINER_pn-rt-tests = "Darren Hart <dvhart@linux.intel.com>"