On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth <k...@openjdk.org> wrote:

> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos <j...@openjdk.org> wrote:
> 
>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green 
>> <12861109+dellgr...@users.noreply.github.com> wrote:
>> 
>>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami 
>>> <2093023+kenziero...@users.noreply.github.com> wrote:
>>> 
>>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>>>> 
>>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green 
>>>>> <12861109+dellgr...@users.noreply.github.com> wrote:
>>>>> 
>>>>>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to 
>>>>>> be able to cross compile javafx for arm hard float. Up to now the 
>>>>>> upstream distribution versions have been debian and raspbian wheezy, but 
>>>>>> these are now end of life and have been archived to servers that have 
>>>>>> different domain names.
>>>>>> 
>>>>>> Tried to change to use jessie but this generates a whole load of  
>>>>>> __THROWNL errors, so for now have updated the domain names to point to 
>>>>>> new servers so that wheezy packages can still be retrieved and cross 
>>>>>> compilation succeeds.
>>>>>> 
>>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870
>>>>>> 
>>>>>> ----------------
>>>>>> 
>>>>>> Commits:
>>>>>>  - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource 
>>>>>> domain names for wheezy
>>>>>> 
>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/8/files
>>>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00
>>>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8231870
>>>>>>   Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>>>>>>   Patch: https://git.openjdk.java.net/jfx/pull/8.diff
>>>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8
>>>>> 
>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232:
>>>>> 
>>>>>> 231:         http://archive.debian.org/debian/ wheezy main armhf \
>>>>>> 232:             libatk1.0-dev \
>>>>>> 233:             libatk1.0-0 \
>>>>> 
>>>>> The use of `http://` URLs to download artifacts is strongly discouraged, 
>>>>> since it isn't secure. Is there a valid `https://` URL that can be used 
>>>>> instead? I note that just substituting `http` with `https` in the above 
>>>>> URL does not work.
>>>>> 
>>>>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392:
>>>>> 
>>>>>> 391:         $DESTINATION \
>>>>>> 392:         http://legacy.raspbian.org/raspbian wheezy firmware armhf \
>>>>>> 393:         libraspberrypi-dev
>>>>> 
>>>>> Same comment hear about using an `https` URL if possible.
>>>>> 
>>>>> I don't have any particular issue with this change. It does highlight an 
>>>>> existing problem where we are still using an `http` URL rather than 
>>>>> `https`. That may or may not be something we can solve here.
>>>> 
>>>> In general a lot of Debian package URLs are not HTTPS by default because 
>>>> of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. 
>>>> However, it does seem like it should at least be supported, so it might be 
>>>> a bug in the `debian.org` server config.
>>>> 
>>>> Additionally, I see that the `getPackages` command doesn't check these 
>>>> signatures. It probably should, but that's another PR.
>>> 
>>> https for legacy.raspbian.org works
>> 
>> I confirm that without the patch, the "cross-build tools" can not be 
>> fetched. With this patch, the tools can be fetched and the build can be 
>> created using these tools.
>> I think this PR is good as it is, as it fixes something that was broken.
>> 
>> However, in general I think the concept of this crosslibs script is broken 
>> for a number of reasons:
>> 1. for none of the other targets, we have a script for downloading the 
>> toolchain. 
>> 2. we have one big blob toolchain for all ARM devices, and do not take 
>> advantage of new compilers/libraries/CPU's. Maintaining toolchains requires 
>> work, and I think it is better that the OpenJFX repository focuses on the 
>> source code, not on the build context.
>> 
>> Rethinking the concept of cross-compiliation involves much more than just 
>> downloading a cross-compiler and libs, and we should not fix that in a rush.
>> 
>> I therefore propose to merge this PR.
> 
> I am going to temporarily change the title in an attempt to force the jcheck 
> bot to run again. I'll change it back once done. Failing this, I will ask the 
> Skara admins to rerun the check if possible. If this doesn't work, we will 
> need to close this PR and have you open a new one.

Looks like that worked and reran jcheck.

PR: https://git.openjdk.java.net/jfx/pull/8

Reply via email to