1.5_M5.rc6 available for testing.

1.5_M5.rc6 available for testing.

[Flanagan, Elizabeth]

All

1.5_M5.rc6 is now available for testing. We've identified one issue
with package index
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5277

Artifacts are available:

http://autobuilder.yoctoproject.org/pub/releases/1.5_M5.rc6

poky 0197e5cb4253d6137b0d166cfcd699d404d2cab3
eclipse-poky-juno 9cff88d9b3043547e3ad6264f5af3f4a8d367496
eclipse-poky-kepler ab0acbd9e7fa3b5bc48af72c569b4ed1f7d686bb
meta-qt3 199986d8fc59a18cd660dbad635076fc9d4d7cc3
meta-minnow 38c2d6ec6c9f8880ff86bed10aa95589850dc214
meta-intel 0dbdf993f8a7e8005248ffac3a5feba1f8ad3623
meta-fsl-arm 60b2189d29851b9bc066e129b2945163214bc742
meta-fsl-ppc 25ee629b826a138ef407c113f776830e5d822c01

-- 
Elizabeth Flanagan
Yocto Project
Build and Release

Re: 1.5_M5.rc6 available for testing.

[Stanacar, StefanX]

On Tue, 2013-10-01 at 23:12 -0700, Flanagan, Elizabeth wrote:
> All
> 
> 1.5_M5.rc6 is now available for testing. We've identified one issue
> with package index
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5277
> 
> Artifacts are available:
> 
> http://autobuilder.yoctoproject.org/pub/releases/1.5_M5.rc6
> 
> poky 0197e5cb4253d6137b0d166cfcd699d404d2cab3
> eclipse-poky-juno 9cff88d9b3043547e3ad6264f5af3f4a8d367496
> eclipse-poky-kepler ab0acbd9e7fa3b5bc48af72c569b4ed1f7d686bb
> meta-qt3 199986d8fc59a18cd660dbad635076fc9d4d7cc3
> meta-minnow 38c2d6ec6c9f8880ff86bed10aa95589850dc214
> meta-intel 0dbdf993f8a7e8005248ffac3a5feba1f8ad3623
> meta-fsl-arm 60b2189d29851b9bc066e129b2945163214bc742
> meta-fsl-ppc 25ee629b826a138ef407c113f776830e5d822c01
> 

Hey Beth,

There is something wierd with that poky revision that AB reports.
It seems the 1.5_M5.rc6 tag points to two different commit ids, and that
confuses people.

This build
http://autobuilder.yoctoproject.org:8011/builders/nightly-x86/builds/313/steps/Building%20Images/logs/stdio

actually shows the right commit id 
meta-yocto-bsp    = "dora:a02280f99f05b1c21de2a78de9222a2f62a0dabc"

but the AB says it's on  0197e5cb4253d6137b0d166cfcd699d404d2cab3 in
properties.

[stefans@firebird poky2]$ git branch
* dora
  master
[stefans@firebird poky2]$ git reset --hard 1.5_M5.rc6
HEAD is now at a02280f README.hardware: update genericx86 hardware
support
[stefans@firebird poky2]$ git log --oneline -n 1
a02280f README.hardware: update genericx86 hardware support
[stefans@firebird poky2]$ 



The Git checkout step from AB confirms this:
It does:
 - git clone --branch dora git://git.yoctoproject.org/poky 
 - then it does: git reset --hard 1.5_M5.rc6
HEAD is now at a02280f README.hardware: update genericx86 hardware
support

 - but: git rev-parse 1.5_M5.rc6 gives:
0197e5cb4253d6137b0d166cfcd699d404d2cab3

Also:
[stefans@firebird poky2]$ git tag -l --contains
0197e5cb4253d6137b0d166cfcd699d404d2cab3
1.5_M5.rc6
[stefans@firebird poky2]$ git tag -l --contains
a02280f99f05b1c21de2a78de9222a2f62a0dabc
1.5_M5.rc6
[stefans@firebird poky2]$ git tag -v 1.5_M5.rc6
object a02280f99f05b1c21de2a78de9222a2f62a0dabc
type commit
tag 1.5_M5.rc6

I don't know how git rev-parse is supposed to work on a tag and why it
returns a different id, but it's a bit confusing.

Cheers,

Stefan

Re: 1.5_M5.rc6 available for testing.

[Stanacar, StefanX]

On Thu, 2013-10-03 at 09:16 +0000, Stanacar, StefanX wrote:
> 


> Also:
> [stefans@firebird poky2]$ git tag -l --contains
> 0197e5cb4253d6137b0d166cfcd699d404d2cab3
> 1.5_M5.rc6
> [stefans@firebird poky2]$ git tag -l --contains
> a02280f99f05b1c21de2a78de9222a2f62a0dabc
> 1.5_M5.rc6
> [stefans@firebird poky2]$ git tag -v 1.5_M5.rc6
> object a02280f99f05b1c21de2a78de9222a2f62a0dabc
> type commit
> tag 1.5_M5.rc6
> 
> I don't know how git rev-parse is supposed to work on a tag and why it
> returns a different id, but it's a bit confusing.
> 

Okay this tagging thing confuses me, although everything seems to be in
orderd the ids are identical.
If someone with more git-fu can explain what and how this happens I'd be
grateful:

[stefans@firebird poky]$ git rev-list 1.5_M5.rc6 | head -n1
a02280f99f05b1c21de2a78de9222a2f62a0dabc
[stefans@firebird poky]$ git show-ref 1.5_M5.rc6
0197e5cb4253d6137b0d166cfcd699d404d2cab3 refs/tags/1.5_M5.rc6
[stefans@firebird poky]$ git rev-parse 1.5_M5.rc6
0197e5cb4253d6137b0d166cfcd699d404d2cab3
[stefans@firebird poky]$ git rev-parse --verify 1.5_M5.rc6^{commit}
a02280f99f05b1c21de2a78de9222a2f62a0dabc
[stefans@firebird poky]$ git show-ref --dereference 1.5_M5.rc6
0197e5cb4253d6137b0d166cfcd699d404d2cab3 refs/tags/1.5_M5.rc6
a02280f99f05b1c21de2a78de9222a2f62a0dabc refs/tags/1.5_M5.rc6^{}
[stefans@firebird poky]$ 

Cheers,
Stefan
 



> Cheers,
> 
> Stefan
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: 1.5_M5.rc6 available for testing.

[Stanacar, StefanX]

On Thu, 2013-10-03 at 09:36 +0000, Stanacar, StefanX wrote:
> 
> On Thu, 2013-10-03 at 09:16 +0000, Stanacar, StefanX wrote:
> > 
> 
> 
> > Also:
> > [stefans@firebird poky2]$ git tag -l --contains
> > 0197e5cb4253d6137b0d166cfcd699d404d2cab3
> > 1.5_M5.rc6
> > [stefans@firebird poky2]$ git tag -l --contains
> > a02280f99f05b1c21de2a78de9222a2f62a0dabc
> > 1.5_M5.rc6
> > [stefans@firebird poky2]$ git tag -v 1.5_M5.rc6
> > object a02280f99f05b1c21de2a78de9222a2f62a0dabc
> > type commit
> > tag 1.5_M5.rc6
> > 
> > I don't know how git rev-parse is supposed to work on a tag and why it
> > returns a different id, but it's a bit confusing.
> > 
> 
> Okay this tagging thing confuses me, although everything seems to be in
> orderd the ids are identical.
> If someone with more git-fu can explain what and how this happens I'd be
> grateful:
> 
> [stefans@firebird poky]$ git rev-list 1.5_M5.rc6 | head -n1
> a02280f99f05b1c21de2a78de9222a2f62a0dabc
> [stefans@firebird poky]$ git show-ref 1.5_M5.rc6
> 0197e5cb4253d6137b0d166cfcd699d404d2cab3 refs/tags/1.5_M5.rc6
> [stefans@firebird poky]$ git rev-parse 1.5_M5.rc6
> 0197e5cb4253d6137b0d166cfcd699d404d2cab3
> [stefans@firebird poky]$ git rev-parse --verify 1.5_M5.rc6^{commit}
> a02280f99f05b1c21de2a78de9222a2f62a0dabc
> [stefans@firebird poky]$ git show-ref --dereference 1.5_M5.rc6
> 0197e5cb4253d6137b0d166cfcd699d404d2cab3 refs/tags/1.5_M5.rc6
> a02280f99f05b1c21de2a78de9222a2f62a0dabc refs/tags/1.5_M5.rc6^{}
> [stefans@firebird poky]$ 
> 

Okay, it's pretty clear. It all comes down to annotated vs lightweight
tags.
1.5_M5.rc6 it's an annotated tag (which contains metadata and the SHA-1
hash of the object it tags) and git gives a SHA-1 hash to all objects
not only commits (tags,trees,blobs).
So when using --dereference option, it will dereference the tag into the
object the tag refers to, and provide information about it instead.

Perhaps the AB should use in it's properties (in Git checkout step) git
rev-parse <tag>^0 to dereference the tag instead of git rev-parse <tag>
From the man-page:

       <rev>^{<type>}, e.g. v0.99.8^{commit}
           A suffix ^ followed by an object type name enclosed in brace
pair
           means the object could be a tag, and dereference the tag
           recursively until an object of that type is found or the
object
           cannot be dereferenced anymore (in which case, barf).
<rev>^0 is a
           short-hand for <rev>^{commit}.


Cheers,

Stefan



> Cheers,
> Stefan
>  
> 
> 
> 
> > Cheers,
> > 
> > Stefan
> > 
> > 
> > 
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto