* openjdk build fails due to checksum mismatches from icedtea-native
@ 2016-10-05 22:50 Randy Mortensen
2016-10-05 23:04 ` Darcy Watkins
0 siblings, 1 reply; 10+ messages in thread
From: Randy Mortensen @ 2016-10-05 22:50 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 287 bytes --]
Using Jethro release and attempting to build either openjdk-7 or 8 fails
when fetching icedtea7-native/2.1.3-r1.0 due to checksum mismatches (on all
the SRC_URI entries).
openjdk-7 did successfully build about a month ago.
Is there a workaround, fix or other suggestions?
Thanks
[-- Attachment #2: Type: text/html, Size: 868 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-05 22:50 openjdk build fails due to checksum mismatches from icedtea-native Randy Mortensen
@ 2016-10-05 23:04 ` Darcy Watkins
2016-10-05 23:45 ` Randy Mortensen
0 siblings, 1 reply; 10+ messages in thread
From: Darcy Watkins @ 2016-10-05 23:04 UTC (permalink / raw)
To: Randy Mortensen; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
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.
---
Regards,
Darcy
Darcy Watkins
Staff Engineer, Firmware
Sierra Wireless
http://sierrawireless.com
[M3]
On Oct 5, 2016, at 3:51 PM, Randy Mortensen <randy.mort@gmail.com<mailto:randy.mort@gmail.com>> wrote:
Using Jethro release and attempting to build either openjdk-7 or 8 fails when fetching icedtea7-native/2.1.3-r1.0 due to checksum mismatches (on all the SRC_URI entries).
openjdk-7 did successfully build about a month ago.
Is there a workaround, fix or other suggestions?
Thanks
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Type: text/html, Size: 2489 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-05 23:04 ` Darcy Watkins
@ 2016-10-05 23:45 ` Randy Mortensen
2016-10-05 23:52 ` Khem Raj
0 siblings, 1 reply; 10+ messages in thread
From: Randy Mortensen @ 2016-10-05 23:45 UTC (permalink / raw)
To: Darcy Watkins; +Cc: Randy Mortensen, yocto
> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-05 23:45 ` Randy Mortensen
@ 2016-10-05 23:52 ` Khem Raj
2016-10-06 1:14 ` Darcy Watkins
0 siblings, 1 reply; 10+ messages in thread
From: Khem Raj @ 2016-10-05 23:52 UTC (permalink / raw)
To: Randy Mortensen; +Cc: Randy Mortensen, yocto
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym@stratagemsystems.com> wrote:
>
>
>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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?
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
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-05 23:52 ` Khem Raj
@ 2016-10-06 1:14 ` Darcy Watkins
2016-10-07 2:07 ` Randy Mortensen
0 siblings, 1 reply; 10+ messages in thread
From: Darcy Watkins @ 2016-10-06 1:14 UTC (permalink / raw)
To: Khem Raj; +Cc: Randy Mortensen, Randy Mortensen, yocto
> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym@stratagemsystems.com> wrote:
>>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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.
---
Regards,
Darcy
Darcy Watkins
Staff Engineer, Firmware
Sierra Wireless
http://sierrawireless.com
[M4]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-06 1:14 ` Darcy Watkins
@ 2016-10-07 2:07 ` Randy Mortensen
2016-10-07 2:35 ` Khem Raj
0 siblings, 1 reply; 10+ messages in thread
From: Randy Mortensen @ 2016-10-07 2:07 UTC (permalink / raw)
To: Darcy Watkins; +Cc: yocto
> On Oct 5, 2016, at 7:14 PM, Darcy Watkins <dwatkins@sierrawireless.com> wrote:
>
>
>
>> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym@stratagemsystems.com> wrote:
>>>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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.
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’m not sure where to go from here to try and resolve so any more help is welcome.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-07 2:07 ` Randy Mortensen
@ 2016-10-07 2:35 ` Khem Raj
2016-10-07 23:14 ` Randy Mortensen
0 siblings, 1 reply; 10+ messages in thread
From: Khem Raj @ 2016-10-07 2:35 UTC (permalink / raw)
To: Randy Mortensen; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]
> On Oct 6, 2016, at 7:07 PM, Randy Mortensen <randy.mort@gmail.com> wrote:
>
>
>> On Oct 5, 2016, at 7:14 PM, Darcy Watkins <dwatkins@sierrawireless.com> wrote:
>>
>>
>>
>>> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym@stratagemsystems.com> wrote:
>>>>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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 ?
> 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’m not sure where to go from here to try and resolve so any more help is welcome.
>
>
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-07 2:35 ` Khem Raj
@ 2016-10-07 23:14 ` Randy Mortensen
2016-10-07 23:21 ` Khem Raj
0 siblings, 1 reply; 10+ messages in thread
From: Randy Mortensen @ 2016-10-07 23:14 UTC (permalink / raw)
To: Khem Raj; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 3140 bytes --]
> On Oct 6, 2016, at 8:35 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> On Oct 6, 2016, at 7:07 PM, Randy Mortensen <randy.mort@gmail.com <mailto:randy.mort@gmail.com>> wrote:
>>
>>
>>> On Oct 5, 2016, at 7:14 PM, Darcy Watkins <dwatkins@sierrawireless.com> wrote:
>>>
>>>
>>>
>>>> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym@stratagemsystems.com> wrote:
>>>>>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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’m not sure where to go from here to try and resolve so any more help is welcome.
[-- Attachment #2: Type: text/html, Size: 6734 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-07 23:14 ` Randy Mortensen
@ 2016-10-07 23:21 ` Khem Raj
2016-10-09 22:11 ` Randy Mortensen
0 siblings, 1 reply; 10+ messages in thread
From: Khem Raj @ 2016-10-07 23:21 UTC (permalink / raw)
To: Randy Mortensen; +Cc: yocto
On Fri, Oct 7, 2016 at 4:14 PM, Randy Mortensen <randy.mort@gmail.com> wrote:
>
> On Oct 6, 2016, at 8:35 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>
> On Oct 6, 2016, at 7:07 PM, Randy Mortensen <randy.mort@gmail.com> wrote:
>
>
> On Oct 5, 2016, at 7:14 PM, Darcy Watkins <dwatkins@sierrawireless.com>
> wrote:
>
>
>
> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym@stratagemsystems.com>
> wrote:
>
> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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
> I’m not sure where to go from here to try and resolve so any more help is
> welcome.
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: openjdk build fails due to checksum mismatches from icedtea-native
2016-10-07 23:21 ` Khem Raj
@ 2016-10-09 22:11 ` Randy Mortensen
0 siblings, 0 replies; 10+ messages in thread
From: Randy Mortensen @ 2016-10-09 22:11 UTC (permalink / raw)
To: Khem Raj; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 3942 bytes --]
> On Oct 7, 2016, at 5:21 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
> On Fri, Oct 7, 2016 at 4:14 PM, Randy Mortensen <randy.mort@gmail.com> wrote:
>>
>> On Oct 6, 2016, at 8:35 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>
>> On Oct 6, 2016, at 7:07 PM, Randy Mortensen <randy.mort@gmail.com> wrote:
>>
>>
>> On Oct 5, 2016, at 7:14 PM, Darcy Watkins <dwatkins@sierrawireless.com>
>> wrote:
>>
>>
>>
>> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <randym@stratagemsystems.com>
>> wrote:
>>
>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatkins@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.
>>
>>
[-- Attachment #2: Type: text/html, Size: 6040 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-10-09 22:11 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-05 22:50 openjdk build fails due to checksum mismatches from icedtea-native Randy Mortensen
2016-10-05 23:04 ` Darcy Watkins
2016-10-05 23:45 ` Randy Mortensen
2016-10-05 23:52 ` Khem Raj
2016-10-06 1:14 ` Darcy Watkins
2016-10-07 2:07 ` Randy Mortensen
2016-10-07 2:35 ` Khem Raj
2016-10-07 23:14 ` Randy Mortensen
2016-10-07 23:21 ` Khem Raj
2016-10-09 22:11 ` Randy Mortensen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.