RFR: 8231870: Updated armv6hf crosslibs script with new domains

Wed Oct 9 16:17:39 UTC 2019

On Wed, 9 Oct 2019 16:10:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> On Wed, 9 Oct 2019 15:18:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>> On Wed, 9 Oct 2019 07:43:43 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote:
>> 
>>> On Tue, 8 Oct 2019 12:02:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>>> 
>>>> On Tue, 8 Oct 2019 11:59:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>>>> 
>>>>> On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>>>>> 
>>>>>> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos <jvos at openjdk.org> wrote:
>>>>>> 
>>>>>>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote:
>>>>>>> 
>>>>>>>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenzierocks at users.noreply.github.com> wrote:
>>>>>>>> 
>>>>>>>>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>>>>>>>>> 
>>>>>>>>>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgreen at 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.
>>>> 
>>>> Please ignore the above comments. I added them to the wrong PR.
>>>> 
>>>> This PR was and still is ready for review.
>>> 
>>> I'll suspend testing of the https domains as previously mentioned.
>> 
>> @dellgreen once you are ready, go ahead and issue the `/integrate` command. Presuming that @johanvos will sponsor this, he can then issue the `/sponsor` command after double-checking the commit message, etc.
> 
> While checking, I notice that this PR has a different title than the title of the corresponding bug in JBS: https://bugs.openjdk.java.net/browse/JDK-8231870.
> @kevin can we simply edit the title of the PR to match the one in JBS?

Btw, my username is @kevinrushforth so you notified someone else on the above comment...

Yes, editing the title to match the JBS issue is a very good thing to do. Since you are sponsoring it, go ahead and do that. I don't know for certain whether the bot will pick it up (since the contributor has already done a `/integrate`) -- it will be a good test.

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