[oe] [meta-java][PATCH 0/4] openjdk-8: update to jdk8u242ga

Jacob Kroon jacob.kroon at gmail.com
Wed Jan 29 19:12:25 UTC 2020


On 1/28/20 1:01 PM, Jacob Kroon wrote:
> On 1/28/20 6:43 AM, Jacob Kroon wrote:
>> On 1/27/20 5:05 PM, Jacob Kroon wrote:
>>> On 1/27/20 3:57 PM, Richard Leitner wrote:
>>>> On Mon, Jan 27, 2020 at 03:10:04PM +0100, Jacob Kroon wrote:
>>>>> On 1/27/20 12:24 PM, Richard Leitner wrote:
>>>>>> This series updates Openjdk 8 to the latest "ga" release 242.
>>>>>>
>>>>>> Successful testing has been done on a fedora-31 build host for
>>>>>> qemuarm64, qemux86-64, qemuarm32 and armv7a.
>>>>>>
>>>>>
>>>>> <cut>
>>>>>
>>>>> I don't know if it is related to my setup, but "bitbake openjre-8" 
>>>>> insists
>>>>> on rebuilding itself every time I run it, and I don't see any 
>>>>> sstate cache
>>>>> being generated for it.
>>>>
>>>> I just tried to reproduce it, but neither for armv7a nor for aarch64
>>>> openjre-8 is rebuiled on the latest poky/oe-core master when nothing 
>>>> was
>>>> changed in meta-java.
>>>>
>>>> So in your case it also rebuilds if you call "bitbake openjre-8"
>>>> directly one-after-another without any change to the layers?
>>>>
>>>
>>> Yes, precisely.
>>>
>>> But.. I think you can ignore this. I suspect I have confused 
>>> bitbake's hashequiv database by pruning old cache-files using the 
>>> sstate-cache-management.sh script.
>>>
>>> Joshua, do you know if that script is supported when using hashequiv ?
>>>
>>> Gonna try and remove cache/ aswell, and see if that helps.
>>>
>>
>> I just retried on a clean build, I wiped everything, and openjre-8 
>> still insists on rebuilding on the second run. I don't know whats 
>> going on here..
> 
> Looks like it is caused by me using rm_work.bbclass, it seems to wipe 
> something that causes the rebuilds.

Actually it looks like openjre-8 and openjdk-8-native cannot rebuild 
from sstate cache, even with rm_work disabled.


More information about the Openembedded-devel mailing list