Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 Rajraj.k...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 Rajraj.k...@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, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 Rajraj.k...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 Rajraj.k...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
On Thu, Oct 20, 2011 at 7:25 AM, Richard Purdie richard.pur...@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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 Rajraj.k...@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
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 Rajraj.k...@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
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.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@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.kam...@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.ha...@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.kam...@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.kam...@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.kam...@intel.com @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef=2.6.18+git RECIPE_MAINTAINER_pn-unifdef = Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@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.kam...@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.kam...@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.kam...@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.kam...@intel.com RECIPE_STATUS_pn-cmake-native=green @@ -5922,9 +5933,6 @@ RECIPE_COMMENTS_pn-pseudo = Yocto Project maintained
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
Koen, Why do you ask ? Nitin -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@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.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@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.kam...@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.ha...@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.kam...@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.kam...@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.kam...@intel.com @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef=2.6.18+git RECIPE_MAINTAINER_pn-unifdef = Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@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.kam...@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.kam...@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.kam...@intel.com
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. Nitin -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@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.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@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.kam...@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.ha...@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.kam...@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.kam...@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.kam...@intel.com @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef=2.6.18+git RECIPE_MAINTAINER_pn-unifdef = Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@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.kam...@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.kam...@intel.com RECIPE_STATUS_pn-libconvert-asn1-perl=green @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl = Aug 13, 2010
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@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-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@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.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@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.kam...@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.ha...@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.kam...@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.kam...@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.kam...@intel.com @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn- unifdef=2.6.18+git RECIPE_MAINTAINER_pn-unifdef = Nitin A Kamble nitin.a.kam...@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.kam...@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.kam...@intel.com RECIPE_STATUS_pn-gmp=green @@ -3110,9 +3120,10
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
Op 19 okt. 2011, om 18:24 heeft Kamble, Nitin A het volgende geschreven: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
On Wed, Oct 19, 2011 at 9:57 AM, Saul Wold saul.w...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
On 10/19/2011 10:00 AM, Khem Raj wrote: On Wed, Oct 19, 2011 at 9:57 AM, Saul Woldsaul.w...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
On Wed, Oct 19, 2011 at 10:45 AM, Saul Wold saul.w...@intel.com wrote: On 10/19/2011 10:00 AM, Khem Raj wrote: On Wed, Oct 19, 2011 at 9:57 AM, Saul Woldsaul.w...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
On Wed, Oct 19, 2011 at 16:30, Khem Raj raj.k...@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. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
On 10/19/2011 12:00 PM, Otavio Salvador wrote: On Wed, Oct 19, 2011 at 16:30, Khem Rajraj.k...@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! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
