RFR: 8231870: Updated armv6hf crosslibs script with new domains
2093023+kenzierocks at github.github.io
Mon Oct 7 17:42:21 UTC 2019
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.
>> - 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.
More information about the openjfx-dev