buildhistory: fix latest_srcrev in the common case
PATCH 1/1 buildhistory: fix latest_srcrev in the common case
From: Christopher Larson <[email protected]>
buildhistory was writing srcrevs.values() as SRCREV when only one srcrev/branch exists. This returns a view of the dictionary values in python 3, and used to return a list in python 2, neither of which is an appropriate value for SRCREV. It was resulting in latest_srcrev files like this:
# SRCREV = "346584bf6e38232be8773c24fd7dedcbd7b3d9ed"
SRCREV = "dict_values(['346584bf6e38232be8773c24fd7dedcbd7b3d9ed'])"Which in turn would result in invalid output in buildhistory-collect-srcrevs. Fix by calling next(iter()) on the .values()
--- meta/classes/buildhistory.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/buildhistory.bbclass +1 -1
@@ -833,7 +833,7 @@ python write_srcrev() { f.write('# SRCREV_%s = "%s"\n' % (name, orig_srcrev)) f.write('SRCREV_%s = "%s"\n' % (name, srcrev)) else: - f.write('SRCREV = "%s"\n' % srcrevs.values()) + f.write('SRCREV = "%s"\n' % next(iter(srcrevs.values()))) if len(tag_srcrevs) > 0: for name, srcrev in tag_srcrevs.items(): f.write('# tag_%s = "%s"\n' % (name, srcrev))
Signature · 1 line
1.9.1
Quoted 7 lines · Andre McCurdy
From: Christopher Larson <[email protected]>
buildhistory was writing
srcrevs.values()as SRCREV when only one srcrev/branch exists. This returns a view of the dictionary values in python 3, and used to return a list in python 2, neither of which is an appropriate value for SRCREV. It was resulting inlatest_srcrevfiles like this:
Quoted 5 lines
# SRCREV = "346584bf6e38232be8773c24fd7dedcbd7b3d9ed" SRCREV = "dict_values(['346584bf6e38232be8773c24fd7dedcbd7b3d9ed'])"Which in turn would result in invalid output in buildhistory-collect-srcrevs. Fix by calling
next(iter())on the.values()
Ping.
Quoted 24 lines
Signed-off-by Christopher Larson <[email protected]>Signed-off-by Ross Burton <[email protected]>(cherry picked from commit ef826a395612400924bbe49859d256b237ff59e1)Signed-off-by Andre McCurdy <[email protected]>--- meta/classes/buildhistory.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)meta/classes/buildhistory.bbclass +1
-2@@ -833,7 +833,7 @@ python write_srcrev() { f.write('# SRCREV_%s = "%s"\n' % (name, orig_srcrev)) f.write('SRCREV_%s = "%s"\n' % (name, srcrev)) else: - f.write('SRCREV = "%s"\n' % srcrevs.values()) + f.write('SRCREV = "%s"\n' % next(iter(srcrevs.values()))) if len(tag_srcrevs) > 0: for name, srcrev in tag_srcrevs.items(): f.write('# tag_%s = "%s"\n' % (name, srcrev)) --1.9.1
Quoted 8 lines · Andre McCurdy
Quoted 7 lines · Andre McCurdy
From: Christopher Larson <[email protected]>
buildhistory was writing
srcrevs.values()as SRCREV when only one srcrev/branch exists. This returns a view of the dictionary values in python 3, and used to return a list in python 2, neither of which is an appropriate value for SRCREV. It was resulting inlatest_srcrevfiles like this:
Quoted 7 lines
Quoted 5 lines
# SRCREV = "346584bf6e38232be8773c24fd7dedcbd7b3d9ed" SRCREV = "dict_values(['346584bf6e38232be8773c24fd7dedcbd7b3d9ed'])"Which in turn would result in invalid output in buildhistory-collect-srcrevs. Fix by calling
next(iter())on the.values()Ping.
Ping again.
This should be a very low risk backport fix for morty but if there are any concerns then please let me know.
Quoted 24 lines
Quoted 24 lines
Signed-off-by Christopher Larson <[email protected]>Signed-off-by Ross Burton <[email protected]>(cherry picked from commit ef826a395612400924bbe49859d256b237ff59e1)Signed-off-by Andre McCurdy <[email protected]>--- meta/classes/buildhistory.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)meta/classes/buildhistory.bbclass +1
-2@@ -833,7 +833,7 @@ python write_srcrev() { f.write('# SRCREV_%s = "%s"\n' % (name, orig_srcrev)) f.write('SRCREV_%s = "%s"\n' % (name, srcrev)) else: - f.write('SRCREV = "%s"\n' % srcrevs.values()) + f.write('SRCREV = "%s"\n' % next(iter(srcrevs.values()))) if len(tag_srcrevs) > 0: for name, srcrev in tag_srcrevs.items(): f.write('# tag_%s = "%s"\n' % (name, srcrev)) --1.9.1
Quoted 12 lines · Andre McCurdy
Quoted 11 lines · Andre McCurdy
Quoted 10 lines · Andre McCurdy
From: Christopher Larson <[email protected]>
buildhistory was writing
srcrevs.values()as SRCREV when only one srcrev/branch exists. This returns a view of the dictionary values in python 3, and used to return a list in python 2, neither of which is an appropriate value for SRCREV. It was resulting inlatest_srcrevfiles like this:# SRCREV = "346584bf6e38232be8773c24fd7dedcbd7b3d9ed" SRCREV = "dict_values(['346584bf6e38232be8773c24fd7dedcbd7b3d9ed'])"
Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
Which in turn would result in invalid output in buildhistory-collect-srcrevs. Fix by calling
next(iter())on the.values()Ping.
Ping again.
This should be a very low risk backport fix for morty but if there are any concerns then please let me know.
morty has been on hold for the new host glib 2.27 and sdk issues. Those issues have been finally addressed and we finally got a clean build. The backlog hold should be lifted and things should be flowing again shortly.
- armin
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Signed-off-by Christopher Larson <[email protected]>Signed-off-by Ross Burton <[email protected]>(cherry picked from commit ef826a395612400924bbe49859d256b237ff59e1)Signed-off-by Andre McCurdy <[email protected]>--- meta/classes/buildhistory.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)meta/classes/buildhistory.bbclass +1
-2@@ -833,7 +833,7 @@ python write_srcrev() { f.write('# SRCREV_%s = "%s"\n' % (name, orig_srcrev)) f.write('SRCREV_%s = "%s"\n' % (name, srcrev)) else: - f.write('SRCREV = "%s"\n' % srcrevs.values()) + f.write('SRCREV = "%s"\n' % next(iter(srcrevs.values()))) if len(tag_srcrevs) > 0: for name, srcrev in tag_srcrevs.items(): f.write('# tag_%s = "%s"\n' % (name, srcrev)) --1.9.1
Quoted 21 lines · On Wed, Apr 4, 2018 at 6:21 PM, akuster808 <[email protected]> wrote:
Quoted 12 lines · Andre McCurdy
Quoted 11 lines · Andre McCurdy
Quoted 10 lines · Andre McCurdy
From: Christopher Larson <[email protected]>
buildhistory was writing
srcrevs.values()as SRCREV when only one srcrev/branch exists. This returns a view of the dictionary values in python 3, and used to return a list in python 2, neither of which is an appropriate value for SRCREV. It was resulting inlatest_srcrevfiles like this:# SRCREV = "346584bf6e38232be8773c24fd7dedcbd7b3d9ed" SRCREV = "dict_values(['346584bf6e38232be8773c24fd7dedcbd7b3d9ed'])"Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
Which in turn would result in invalid output in buildhistory-collect-srcrevs. Fix by calling
next(iter())on the.values()Ping.
Ping again.
This should be a very low risk backport fix for morty but if there are any concerns then please let me know.
Quoted 6 lines
morty has been on hold for the new host glib 2.27 and sdk issues. Those issues have been finally addressed and we finally got a clean build. The backlog hold should be lifted and things should be flowing again shortly.
OK, thanks!
I checked oe-core/morty-next and oe-core-contrib/stable/morty-next and didn't see it there. I forgot to check poky-contrib/stable/morty-next as well... :-)
If poky-contrib is the official pre-staging area before oe-core morty-next, then perhaps you could remove the oe-core-contrib stable/morty-next branch to avoid confusion?