openh264: switch away from github archive
PATCH v2 1/1 openh264: switch away from github archive
Since we know that github archives which are automatically generated have a tendency to change their checksums[1], switch to using a git clone.
[1] http://lists.openembedded.org/pipermail/openembedded-devel/2017-September/114916.html
---
Changes since v1:
- replace the frankenstein local variable name OPENHBRANCH with simply BRANCH to hold the name of the branch to use
--- .../recipes-multimedia/openh264/openh264_1.7.0.bb | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
meta-multimedia/recipes-multimedia/openh264/openh264_1.7.0.bb +4 -3
@@ -11,9 +11,10 @@ LICENSE = "BSD-2-Clause" LICENSE_FLAGS = "commercial" LIC_FILES_CHKSUM = "file://LICENSE;md5=bb6d3771da6a07d33fd50d4d9aa73bcf" -SRC_URI = "https://github.com/cisco/openh264/archive/v${PV}.tar.gz" -SRC_URI[md5sum] = "93da4e76cfda7ede8fd2df51b0021efd" -SRC_URI[sha256sum] = "9c07c38d7de00046c9c52b12c76a2af7648b70d05bd5460c8b67f6895738653f" +S = "${WORKDIR}/git" +SRCREV = "a180c9d4d6f1a4830ca9eed9d159d54996bd63cb" +BRANCH = "openh264v1.7" +SRC_URI = "git://github.com/cisco/openh264.git;protocol=https;branch=${BRANCH};" COMPATIBLE_MACHINE_armv7a = "(.*)" COMPATIBLE_MACHINE_aarch64 = "(.*)"
Signature · 1 line
2.17.0.rc2.3.gc2a499e6c
Quoted 11 lines · Trevor Woerner
Since we know that github archives which are automatically generated have a tendency to change their checksums[1], switch to using a git clone.
[1] http://lists.openembedded.org/pipermail/openembedded-devel/2017-September/114916.html
Signed-off-by Trevor Woerner <[email protected]>---
Changes since v1:
- replace the frankenstein local variable name OPENHBRANCH with simply BRANCH to hold the name of the branch to use
This fails to build: please see
http://errors.yoctoproject.org/Errors/Details/178572/
Quoted 23 lines
--- .../recipes-multimedia/openh264/openh264_1.7.0.bb | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)meta-multimedia/recipes-multimedia/openh264/openh264_1.7.0.bb +4
-3@@ -11,9 +11,10 @@ LICENSE = "BSD-2-Clause" LICENSE_FLAGS = "commercial" LIC_FILES_CHKSUM = "file://LICENSE;md5=bb6d3771da6a07d33fd50d4d9aa73bcf" -SRC_URI = "https://github.com/cisco/openh264/archive/v${PV}.tar.gz" -SRC_URI[md5sum] = "93da4e76cfda7ede8fd2df51b0021efd" -SRC_URI[sha256sum] = "9c07c38d7de00046c9c52b12c76a2af7648b70d05bd5460c8b67f6895738653f" +S = "${WORKDIR}/git" +SRCREV = "a180c9d4d6f1a4830ca9eed9d159d54996bd63cb" +BRANCH = "openh264v1.7" +SRC_URI = "git://github.com/cisco/openh264.git;protocol=https;branch=${BRANCH};" COMPATIBLE_MACHINE_armv7a = "(.*)" COMPATIBLE_MACHINE_aarch64 = "(.*)"
Quoted 13 lines · On Tue, May 15, 2018 at 10:45 AM, akuster808 <[email protected]> wrote:
Quoted 1 line · Trevor Woerner
Since we know that github archives which are automatically generated
have a
Quoted 3 lines
tendency to change their checksums[1], switch to using a git clone.
[1] http://lists.openembedded.org/pipermail/openembedded-devel/
2017-September/114916.html
Quoted 4 lines
Signed-off-by Trevor Woerner <[email protected]>---
Quoted 6 lines
Quoted 2 lines
Changes since v1:
- replace the frankenstein local variable name OPENHBRANCH with simplyBRANCH
Quoted 1 line
to hold the name of the branch to use
This fails to build: please see
http://errors.yoctoproject.org/Errors/Details/178572/
As it turns out, even without this patch, building the existing openh264 recipe in master for qemux86 fails exactly the same way. The really odd thing is, I don't see any indication of this failure in any of the "state of the world" build reports. Do the "state of the world" builds not build against MACHINE="qemux86"? Or maybe openh264 is skipped (perhaps due to LICENSE_FLAGS = "commercial")?
I'm not entirely surprised this patch doesn't introduce a new problem, its only difference against the original is to fetch from git rather that an automatically generated github archive. If the auto-generated archive succeeded but a git clone of the exact same SHA failed, that would be news indeed!
I assume that although my patches aren't introducing a new build failure, I should probably investigate fixing it anyway?
The existing recipe has provisions for i386. If I understand correctly, qemux86 is i586 (?), and meta-intel's intel-core2-32 is i686 (?). Do I duplicate the i386 provisions for i586 and i686? Is there an easier way to specify all 32-bit IA systems? Otherwise I guess another option is to disable 32-bit IA COMPATIBLE_MACHINEs?
Quoted 4 lines · Trevor Woerner
The existing recipe has provisions for i386. If I understand correctly, qemux86 is i586 (?), and meta-intel's intel-core2-32 is i686 (?). Do I duplicate the i386 provisions for i586 and i686? Is there an easier way to specify all 32-bit IA systems?
Does it work if you use _x86 instead of _i386?
Thanks,
Anuj
Hi Anuj,
Quoted 9 lines · Anuj Mittal
Quoted 3 lines · Trevor Woerner
The existing recipe has provisions for i386. If I understand correctly, qemux86 is i586 (?), and meta-intel's intel-core2-32 is i686 (?). Do I duplicate the i386 provisions for i586 and i686? Is there an easier way
to
Quoted 1 line
specify all 32-bit IA systems?
Does it work if you use
_x86instead of_i386?
Yes, that seems to help, thanks!