Patchwork [4/5] clutter_git: update to 1.8.2 tag

login
register
mail settings
Submitter Joshua Lock
Date Dec. 13, 2011, 8:24 p.m.
Message ID <ae691bf123b40864556a105f325aff26a6878cdb.1323807692.git.josh@linux.intel.com>
Download mbox | patch
Permalink /patch/16859/
State Accepted
Commit 12b03b946ba5b08f93b780b6b3f7115fcf76fdcb
Headers show

Comments

Joshua Lock - Dec. 13, 2011, 8:24 p.m.
Eventual plan is to start building bleeding git again, so we'd like to keep
the recipe around and relatively up to date.

Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
 meta/recipes-graphics/clutter/clutter_git.bb |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
Khem Raj - Dec. 13, 2011, 8:34 p.m.
On Tue, Dec 13, 2011 at 12:24 PM, Joshua Lock <josh@linux.intel.com> wrote:
> -SRCREV = "39db46123ed6bbbc3e6ad359a64d4d344ca9e11b"
> -PV = "1.8.0+git${SRCPV}"
> +# the 1.8.2 tag
> +SRCREV = "9041ea42655dfc1422ce88eab931382dd400d13a"
> +PV = "1.8.2+git${SRCPV}"

you could also use the tag name instead of SHA for SRCREV I think
Joshua Lock - Dec. 13, 2011, 8:40 p.m.
On 13/12/11 12:34, Khem Raj wrote:
> On Tue, Dec 13, 2011 at 12:24 PM, Joshua Lock <josh@linux.intel.com> wrote:
>> -SRCREV = "39db46123ed6bbbc3e6ad359a64d4d344ca9e11b"
>> -PV = "1.8.0+git${SRCPV}"
>> +# the 1.8.2 tag
>> +SRCREV = "9041ea42655dfc1422ce88eab931382dd400d13a"
>> +PV = "1.8.2+git${SRCPV}"
> 
> you could also use the tag name instead of SHA for SRCREV I think

Indeed we can, however we've seen problems which I can't recall the
details of in the past when doing so. Therefore I decided to avoid it
this time.

Cheers,
Joshua
Paul Eggleton - Dec. 13, 2011, 9:20 p.m.
On Tuesday 13 December 2011 12:40:40 Joshua Lock wrote:
> On 13/12/11 12:34, Khem Raj wrote:
> > On Tue, Dec 13, 2011 at 12:24 PM, Joshua Lock <josh@linux.intel.com> 
wrote:
> >> -SRCREV = "39db46123ed6bbbc3e6ad359a64d4d344ca9e11b"
> >> -PV = "1.8.0+git${SRCPV}"
> >> +# the 1.8.2 tag
> >> +SRCREV = "9041ea42655dfc1422ce88eab931382dd400d13a"
> >> +PV = "1.8.2+git${SRCPV}"
> > 
> > you could also use the tag name instead of SHA for SRCREV I think
> 
> Indeed we can, however we've seen problems which I can't recall the
> details of in the past when doing so. Therefore I decided to avoid it
> this time.

It does work, it just forces a fetch on every parse which is not really 
desirable. It's really no hardship to use the SHA1 especially if it's 
accompanied by a comment with the corresponding tag.

Cheers,
Paul
Saul Wold - Dec. 13, 2011, 10:18 p.m.
On 12/13/2011 01:20 PM, Paul Eggleton wrote:
> On Tuesday 13 December 2011 12:40:40 Joshua Lock wrote:
>> On 13/12/11 12:34, Khem Raj wrote:
>>> On Tue, Dec 13, 2011 at 12:24 PM, Joshua Lock<josh@linux.intel.com>
> wrote:
>>>> -SRCREV = "39db46123ed6bbbc3e6ad359a64d4d344ca9e11b"
>>>> -PV = "1.8.0+git${SRCPV}"
>>>> +# the 1.8.2 tag
>>>> +SRCREV = "9041ea42655dfc1422ce88eab931382dd400d13a"
>>>> +PV = "1.8.2+git${SRCPV}"
>>>
>>> you could also use the tag name instead of SHA for SRCREV I think
>>
>> Indeed we can, however we've seen problems which I can't recall the
>> details of in the past when doing so. Therefore I decided to avoid it
>> this time.
>
> It does work, it just forces a fetch on every parse which is not really
> desirable. It's really no hardship to use the SHA1 especially if it's
> accompanied by a comment with the corresponding tag.
>
It will also break BB_NO_NETWORK builds with a tag, because of that 
fetch lookup, to it's preferred to use the SHA SRCREV with a Tag Comment.

Sau!

> Cheers,
> Paul
>
Khem Raj - Dec. 13, 2011, 10:39 p.m.
On (13/12/11 21:20), Paul Eggleton wrote:
> > > you could also use the tag name instead of SHA for SRCREV I think
> > 
> > Indeed we can, however we've seen problems which I can't recall the
> > details of in the past when doing so. Therefore I decided to avoid it
> > this time.
> 
> It does work, it just forces a fetch on every parse which is not really 
> desirable. It's really no hardship to use the SHA1 especially if it's 
> accompanied by a comment with the corresponding tag.

is this some limitation of fetchers ?
Paul Eggleton - Dec. 13, 2011, 10:43 p.m.
On Tuesday 13 December 2011 14:39:28 Khem Raj wrote:
> is this some limitation of fetchers ?

Not really, it's just we need the actual SHA1 to construct ${PV} at parse 
time, and if the specified SRCREV is not a SHA1 the git fetcher has no way of 
knowing if it refers to a tag or a branch (which may also have changed since 
the last parse) until it can contact the repository, so it has to do that 
immediately.

Cheers,
Paul

Patch

diff --git a/meta/recipes-graphics/clutter/clutter_git.bb b/meta/recipes-graphics/clutter/clutter_git.bb
index db8c712..d598b4a 100644
--- a/meta/recipes-graphics/clutter/clutter_git.bb
+++ b/meta/recipes-graphics/clutter/clutter_git.bb
@@ -3,8 +3,9 @@  require clutter-package.inc
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
-SRCREV = "39db46123ed6bbbc3e6ad359a64d4d344ca9e11b"
-PV = "1.8.0+git${SRCPV}"
+# the 1.8.2 tag
+SRCREV = "9041ea42655dfc1422ce88eab931382dd400d13a"
+PV = "1.8.2+git${SRCPV}"
 PR = "r0"
 
 DEFAULT_PREFERENCE = "-1"