* [PATCH 0/1] base-files: do_install.sigdata: remove the depends on DATE @ 2014-03-25 3:10 Robert Yang 2014-03-25 3:10 ` [PATCH 1/1] " Robert Yang 0 siblings, 1 reply; 8+ messages in thread From: Robert Yang @ 2014-03-25 3:10 UTC (permalink / raw) To: openembedded-core The following changes since commit 12217d8620e434a88433e7a60ff7fa8a1b51c6b1: meta/conf/bitbake.conf: add STAMPCLEAN to BB_HASHBASE_WHITELIST (2014-03-25 10:14:26 +0800) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/basefiles http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/basefiles Robert Yang (1): base-files: do_install.sigdata: remove the depends on DATE meta/recipes-core/base-files/base-files_3.0.14.bb | 1 + 1 file changed, 1 insertion(+) -- 1.8.3.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE 2014-03-25 3:10 [PATCH 0/1] base-files: do_install.sigdata: remove the depends on DATE Robert Yang @ 2014-03-25 3:10 ` Robert Yang 2014-03-27 17:21 ` Chris Larson 0 siblings, 1 reply; 8+ messages in thread From: Robert Yang @ 2014-03-25 3:10 UTC (permalink / raw) To: openembedded-core If we run "bitbake -S base-files" today, and re-run it tomorrow with nothing changed, we would see that the do_install.sigdata changes because of: do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE We had set: IMAGE_NAME[vardepsexclude] += "DATETIME" in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem. [YOCTO #6032] Signed-off-by: Robert Yang <liezhi.yang@windriver.com> --- meta/recipes-core/base-files/base-files_3.0.14.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb b/meta/recipes-core/base-files/base-files_3.0.14.bb index cee19a1..9699e31 100644 --- a/meta/recipes-core/base-files/base-files_3.0.14.bb +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb @@ -103,6 +103,7 @@ do_install () { ln -sf /proc/mounts ${D}${sysconfdir}/mtab } +DISTRO_VERSION[vardepsexclude] += "DATE" do_install_basefilesissue () { if [ "${hostname}" != "" ]; then if [ -n "${MACHINE}" -a "${hostname}" = "openembedded" ]; then -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE 2014-03-25 3:10 ` [PATCH 1/1] " Robert Yang @ 2014-03-27 17:21 ` Chris Larson 2014-03-27 17:49 ` Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: Chris Larson @ 2014-03-27 17:21 UTC (permalink / raw) To: Robert Yang; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1116 bytes --] On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang <liezhi.yang@windriver.com>wrote: > If we run "bitbake -S base-files" today, and re-run it tomorrow with > nothing changed, we would see that the do_install.sigdata changes > because of: > > do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE > > We had set: > IMAGE_NAME[vardepsexclude] += "DATETIME" > in meta/conf/bitbake.conf, we can set a similar line in > base-files_3.0.14.bb to fix the problem. > > [YOCTO #6032] > > Signed-off-by: Robert Yang <liezhi.yang@windriver.com> > Wont't this mean base-files wouldn't be rebuilt when the day changes? This seems problematic to me. I think this is a legitimate case for a checksum change. If the distro version changes due to the date changing, and the base-files includes the distro version in the issue file, then we'd *want* base-files to rebuild to ensure the issue file is correct, otherwise it'd be inaccurate, no? -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics [-- Attachment #2: Type: text/html, Size: 1742 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE 2014-03-27 17:21 ` Chris Larson @ 2014-03-27 17:49 ` Richard Purdie 2014-03-27 17:53 ` Chris Larson 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2014-03-27 17:49 UTC (permalink / raw) To: Chris Larson; +Cc: Patches and discussions about the oe-core layer On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote: > > On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang > <liezhi.yang@windriver.com> wrote: > If we run "bitbake -S base-files" today, and re-run it > tomorrow with > nothing changed, we would see that the do_install.sigdata > changes > because of: > > do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> > DATE > > We had set: > IMAGE_NAME[vardepsexclude] += "DATETIME" > in meta/conf/bitbake.conf, we can set a similar line in > base-files_3.0.14.bb to fix the problem. > > [YOCTO #6032] > > Signed-off-by: Robert Yang <liezhi.yang@windriver.com> > > Wont't this mean base-files wouldn't be rebuilt when the day changes? > This seems problematic to me. I think this is a legitimate case for a > checksum change. If the distro version changes due to the date > changing, and the base-files includes the distro version in the issue > file, then we'd *want* base-files to rebuild to ensure the issue file > is correct, otherwise it'd be inaccurate, no? > I'm torn on this. Package feed creators probably don't want a package feed where the package changes daily but I can see this from both sides, I have often wondered why my build was rebuilding base-files... Cheers, Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE 2014-03-27 17:49 ` Richard Purdie @ 2014-03-27 17:53 ` Chris Larson 2014-03-27 18:13 ` Martin Jansa 0 siblings, 1 reply; 8+ messages in thread From: Chris Larson @ 2014-03-27 17:53 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 2000 bytes --] On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote: > > > > On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang > > <liezhi.yang@windriver.com> wrote: > > If we run "bitbake -S base-files" today, and re-run it > > tomorrow with > > nothing changed, we would see that the do_install.sigdata > > changes > > because of: > > > > do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> > > DATE > > > > We had set: > > IMAGE_NAME[vardepsexclude] += "DATETIME" > > in meta/conf/bitbake.conf, we can set a similar line in > > base-files_3.0.14.bb to fix the problem. > > > > [YOCTO #6032] > > > > Signed-off-by: Robert Yang <liezhi.yang@windriver.com> > > > > Wont't this mean base-files wouldn't be rebuilt when the day changes? > > This seems problematic to me. I think this is a legitimate case for a > > checksum change. If the distro version changes due to the date > > changing, and the base-files includes the distro version in the issue > > file, then we'd *want* base-files to rebuild to ensure the issue file > > is correct, otherwise it'd be inaccurate, no? > > > I'm torn on this. Package feed creators probably don't want a package > feed where the package changes daily but I can see this from both sides, > I have often wondered why my build was rebuilding base-files... Perhaps we should either not use DATE/TIME in the distro version at all, or have a variable which is the current date, and a variable which locks to the date of the creation of the TMPDIR but doesn't change after that, or something, as a more persistent build environment identifier to use for such cases. *shrug* -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics [-- Attachment #2: Type: text/html, Size: 2817 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE 2014-03-27 17:53 ` Chris Larson @ 2014-03-27 18:13 ` Martin Jansa 2014-03-27 18:31 ` Mark Hatle 0 siblings, 1 reply; 8+ messages in thread From: Martin Jansa @ 2014-03-27 18:13 UTC (permalink / raw) To: Chris Larson; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 2625 bytes --] On Thu, Mar 27, 2014 at 10:53:20AM -0700, Chris Larson wrote: > On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie < > richard.purdie@linuxfoundation.org> wrote: > > > On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote: > > > > > > On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang > > > <liezhi.yang@windriver.com> wrote: > > > If we run "bitbake -S base-files" today, and re-run it > > > tomorrow with > > > nothing changed, we would see that the do_install.sigdata > > > changes > > > because of: > > > > > > do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> > > > DATE > > > > > > We had set: > > > IMAGE_NAME[vardepsexclude] += "DATETIME" > > > in meta/conf/bitbake.conf, we can set a similar line in > > > base-files_3.0.14.bb to fix the problem. > > > > > > [YOCTO #6032] > > > > > > Signed-off-by: Robert Yang <liezhi.yang@windriver.com> > > > > > > Wont't this mean base-files wouldn't be rebuilt when the day changes? > > > This seems problematic to me. I think this is a legitimate case for a > > > checksum change. If the distro version changes due to the date > > > changing, and the base-files includes the distro version in the issue > > > file, then we'd *want* base-files to rebuild to ensure the issue file > > > is correct, otherwise it'd be inaccurate, no? > > > > > I'm torn on this. Package feed creators probably don't want a package > > feed where the package changes daily but I can see this from both sides, > > I have often wondered why my build was rebuilding base-files... > > > Perhaps we should either not use DATE/TIME in the distro version at all, or > have a variable which is the current date, and a variable which locks to > the date of the creation of the TMPDIR but doesn't change after that, or > something, as a more persistent build environment identifier to use for > such cases. *shrug* I think that the DATE specific part should be moved to separate recipe which will clearly indicate it's just "build version". I'm using shr-version recipe which just puts file in sysconfdir so it's not so surprising to see shr-version recipe being rebuilt everyday and I still know when the user last updated from feed. It's also useful to pull such recipe into image by IMAGE_INSTALL not through packagegroup (as otherwise the packagegroup could be rebuilt every day as well - at least until runtime deps for packagegroups were excluded in signature handler). -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE 2014-03-27 18:13 ` Martin Jansa @ 2014-03-27 18:31 ` Mark Hatle 2014-03-28 1:44 ` Robert Yang 0 siblings, 1 reply; 8+ messages in thread From: Mark Hatle @ 2014-03-27 18:31 UTC (permalink / raw) To: openembedded-core On 3/27/14, 1:13 PM, Martin Jansa wrote: > On Thu, Mar 27, 2014 at 10:53:20AM -0700, Chris Larson wrote: >> On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie < >> richard.purdie@linuxfoundation.org> wrote: >> >>> On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote: >>>> >>>> On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang >>>> <liezhi.yang@windriver.com> wrote: >>>> If we run "bitbake -S base-files" today, and re-run it >>>> tomorrow with >>>> nothing changed, we would see that the do_install.sigdata >>>> changes >>>> because of: >>>> >>>> do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> >>>> DATE >>>> >>>> We had set: >>>> IMAGE_NAME[vardepsexclude] += "DATETIME" >>>> in meta/conf/bitbake.conf, we can set a similar line in >>>> base-files_3.0.14.bb to fix the problem. >>>> >>>> [YOCTO #6032] >>>> >>>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com> >>>> >>>> Wont't this mean base-files wouldn't be rebuilt when the day changes? >>>> This seems problematic to me. I think this is a legitimate case for a >>>> checksum change. If the distro version changes due to the date >>>> changing, and the base-files includes the distro version in the issue >>>> file, then we'd *want* base-files to rebuild to ensure the issue file >>>> is correct, otherwise it'd be inaccurate, no? >>>> >>> I'm torn on this. Package feed creators probably don't want a package >>> feed where the package changes daily but I can see this from both sides, >>> I have often wondered why my build was rebuilding base-files... >> >> >> Perhaps we should either not use DATE/TIME in the distro version at all, or >> have a variable which is the current date, and a variable which locks to >> the date of the creation of the TMPDIR but doesn't change after that, or >> something, as a more persistent build environment identifier to use for >> such cases. *shrug* > > I think that the DATE specific part should be moved to separate recipe > which will clearly indicate it's just "build version". > > I'm using shr-version recipe which just puts file in sysconfdir so it's > not so surprising to see shr-version recipe being rebuilt everyday and I > still know when the user last updated from feed. > > It's also useful to pull such recipe into image by IMAGE_INSTALL not > through packagegroup (as otherwise the packagegroup could be rebuilt > every day as well - at least until runtime deps for packagegroups were > excluded in signature handler). This is a good place where separating version/build information from the basefiles makes a lot of sense. Rebuilding one small package daily for the purpose of knowing you are "current" is a lot better then potentially screwing with the base-files on the system (unless they've been changed and need to be updated.) --Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE 2014-03-27 18:31 ` Mark Hatle @ 2014-03-28 1:44 ` Robert Yang 0 siblings, 0 replies; 8+ messages in thread From: Robert Yang @ 2014-03-28 1:44 UTC (permalink / raw) To: Mark Hatle, Chris Larson, Martin Jansa, Purdie, Richard; +Cc: openembedded-core On 03/28/2014 02:31 AM, Mark Hatle wrote: > On 3/27/14, 1:13 PM, Martin Jansa wrote: >> On Thu, Mar 27, 2014 at 10:53:20AM -0700, Chris Larson wrote: >>> On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie < >>> richard.purdie@linuxfoundation.org> wrote: >>> >>>> On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote: >>>>> >>>>> On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang >>>>> <liezhi.yang@windriver.com> wrote: >>>>> If we run "bitbake -S base-files" today, and re-run it >>>>> tomorrow with >>>>> nothing changed, we would see that the do_install.sigdata >>>>> changes >>>>> because of: >>>>> >>>>> do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> >>>>> DATE >>>>> >>>>> We had set: >>>>> IMAGE_NAME[vardepsexclude] += "DATETIME" >>>>> in meta/conf/bitbake.conf, we can set a similar line in >>>>> base-files_3.0.14.bb to fix the problem. >>>>> >>>>> [YOCTO #6032] >>>>> >>>>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com> >>>>> >>>>> Wont't this mean base-files wouldn't be rebuilt when the day changes? >>>>> This seems problematic to me. I think this is a legitimate case for a >>>>> checksum change. If the distro version changes due to the date >>>>> changing, and the base-files includes the distro version in the issue >>>>> file, then we'd *want* base-files to rebuild to ensure the issue file >>>>> is correct, otherwise it'd be inaccurate, no? >>>>> >>>> I'm torn on this. Package feed creators probably don't want a package >>>> feed where the package changes daily but I can see this from both sides, >>>> I have often wondered why my build was rebuilding base-files... >>> >>> >>> Perhaps we should either not use DATE/TIME in the distro version at all, or >>> have a variable which is the current date, and a variable which locks to >>> the date of the creation of the TMPDIR but doesn't change after that, or >>> something, as a more persistent build environment identifier to use for >>> such cases. *shrug* >> >> I think that the DATE specific part should be moved to separate recipe >> which will clearly indicate it's just "build version". >> >> I'm using shr-version recipe which just puts file in sysconfdir so it's >> not so surprising to see shr-version recipe being rebuilt everyday and I >> still know when the user last updated from feed. >> >> It's also useful to pull such recipe into image by IMAGE_INSTALL not >> through packagegroup (as otherwise the packagegroup could be rebuilt >> every day as well - at least until runtime deps for packagegroups were >> excluded in signature handler). > > This is a good place where separating version/build information from the > basefiles makes a lot of sense. Rebuilding one small package daily for the > purpose of knowing you are "current" is a lot better then potentially screwing > with the base-files on the system (unless they've been changed and need to be > updated.) > After reading the threads, I think that we can file an enhancement bug for 1.7 to move the DATE/TIME related info to a separate recipe. For 1.6, I think that this patch is fine, the base-files get rebuild when DATE changes, but the image doesn't, and people may get confused since he can't reproduce this in a same day. I'd like to file an enhancement bug for 1.7 and add you to CC list if you are fine. // Robert > --Mark > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-03-28 1:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-25 3:10 [PATCH 0/1] base-files: do_install.sigdata: remove the depends on DATE Robert Yang 2014-03-25 3:10 ` [PATCH 1/1] " Robert Yang 2014-03-27 17:21 ` Chris Larson 2014-03-27 17:49 ` Richard Purdie 2014-03-27 17:53 ` Chris Larson 2014-03-27 18:13 ` Martin Jansa 2014-03-27 18:31 ` Mark Hatle 2014-03-28 1:44 ` Robert Yang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.