[yocto] openjdk build fails due to checksum mismatches from icedtea-native
Randy Mortensen
randy.mort at gmail.com
Sun Oct 9 15:11:23 PDT 2016
> On Oct 7, 2016, at 5:21 PM, Khem Raj <raj.khem at gmail.com> wrote:
>
> On Fri, Oct 7, 2016 at 4:14 PM, Randy Mortensen <randy.mort at gmail.com> wrote:
>>
>> On Oct 6, 2016, at 8:35 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>
>>
>> On Oct 6, 2016, at 7:07 PM, Randy Mortensen <randy.mort at gmail.com> wrote:
>>
>>
>> On Oct 5, 2016, at 7:14 PM, Darcy Watkins <dwatkins at sierrawireless.com>
>> wrote:
>>
>>
>>
>> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>
>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym at stratagemsystems.com>
>> wrote:
>>
>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins at sierrawireless.com>
>> wrote:
>>
>> From what I gleaned from recent discussions of fetcher errors, this is
>> somehow connected with rollout of Python related security fixes to various
>> Linux distributions and/or some ...-native recipes.
>>
>> It was a bunch of tar balls that are named as mercurial hashes from within
>> iced tea rather than the yocto fetch. I worked around it by grabbing the
>> tarballs from a different checkout since I didn't have time to dig into it.
>>
>> It affected a fresh checkout I was building from scratch.
>>
>> Thanks for the response. This also happened to me when trying to build from
>> scratch.
>> For my clarification, did you already have the tar balls downloaded or were
>> you able to download them from a previous (icedtea) commit somehow?
>>
>>
>> I had the tar balls in a different build that I had around for some time.
>> The reason I never cached these ones in a shared location on our server was
>> I felt that tar balls with small hashes as filenames was too prone to
>> collisions, especially without a package name as a prefix. I don't know if
>> that is a convention of iced tea, or how the fetcher handles mercurial.
>>
>> Can you check if the tarballs have been rebuilt upstream ? if so we should
>> try to find out what changed.
>> It could also be an oversight that a recipe update forgot or updated the
>> checksums wrongly. but we should try to root cause it
>>
>>
>> I agree here. We should root cause it.
>>
>>
>> I’m not sure how this is all supposed to work, but I managed to get past the
>> fetch failures by changing the md5sum and sha256sum checksums in
>> icedtea7-native_2.1.3.bb.
>> I used the the checksums helpfully suggested by bitbake when it reported the
>> errors.
>>
>> I compared one of the problematic tar balls with a “good” one from a
>> previous download and the only change I could identify was 3 extra lines
>> added to a hidden file .hgtag (which I presume maps a tag to a commit). Not
>> sure why requesting the same hg commit results in a different tarball
>> output.
>>
>>
>> could it be that its generating the tarballs from mercurial directly and
>> thats flawed somehow ?
>>
>> That seems likely but I don’t know how to fix that.
>>
>> I also don’t understand why the configure task fails after the fetch task
>> successfully downloads the tarballs.
>>
>>
>>
>> Now however iced tea fails to configure due to checksum errors. The
>> configure task seems to re-download each tarball and check the sha256sum
>> which is failing.
>>
>
> I wonder if this failure will still happen again when it rebuilds the
> tarball internally. I have
> a hunch that might happen again
Probably.
I did manage a workaround by implementing two changes. One was to override all the SRC_URI md5sum and sha256sum values from a recipes-core/icedtea/icedtea7-native_2.1.3.bbappend file.
The other was to add a patch to fix the checksums listed in icedtea-2.1.3/Makefile.am by adding a patch file to the SRC_URI in the same bbappend file.
(Apparently the old (erroneous) checksums are baked-into Makefile.am.)
>
>> I’m not sure where to go from here to try and resolve so any more help is
>> welcome.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20161009/942667ca/attachment.html>
More information about the yocto
mailing list