Package Details: jre8 8u441-1

Git Clone URL: https://aur.archlinux.org/jre8.git (read-only, click to copy)
Package Base: jre8
Description: Oracle Java 8 Runtime Environment LTS
Upstream URL: https://www.java.com/en/download/manual.jsp
Keywords: java-openjfx java-runtime-headless-jre java-runtime-jre java-web-start-jre
Licenses: custom:Oracle
Provides: java-openjfx, java-runtime, java-runtime-headless, java-runtime-headless-jre, java-runtime-jre, java-web-start, java-web-start-jre
Submitter: Det
Maintainer: severach
Last Packager: severach
Votes: 44
Popularity: 0.064261
First Submitted: 2017-09-21 22:18 (UTC)
Last Updated: 2025-02-04 03:21 (UTC)

Dependencies (8)

Required by (1803)

Sources (2)

Latest Comments

1 2 3 Next › Last »

khvalera commented on 2025-03-20 16:56 (UTC)

No file /usr/lib/jvm/java-8-jre/jre/lib/amd64/libnpjp2.so

severach commented on 2022-12-16 05:02 (UTC) (edited on 2022-12-16 05:03 (UTC) by severach)

mv prevents repackaging in general

mv kills makepkg -e and makepkg -R. A bin package has no need of those and should be built with makepkg -scC. These mv look to me like they didn't want the file in the old location leading to install&&rm.

actions ... that should be moved to prepare

They could be but this is how the Arch devs did it. No substantive difference between prepare and package for a bin package.

I like all my related packages to be diff similar so everyone can check that one version doesn't have any hidden strangeness and I can propagate patches across versions easily. If you want to make a major change like this you'll need to push it up through the jdk jre versions.

eclairevoyant commented on 2022-12-11 20:31 (UTC)

Aside from being out of date, there's a lot of actions (edits to files, rm commands to clean up the source files) that should be moved to prepare(), and there's not a good reason to use mv when install suffices (and mv prevents repackaging in general).

rekman commented on 2022-11-17 13:25 (UTC) 

==> Retrieving sources...
  -> Downloading jre-8u341-linux-x64.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0    22    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404
==> ERROR: Failure while downloading https://javadl.oracle.com/webapps/download/AutoDL?BundleId=246799_424b9da4b48848379167015dcc250d8d

This appears to be a server-side problem because as of writing none of the links at https://www.java.com/en/download/ work; they all give this error "unrecognized arguments".

severach commented on 2021-02-09 03:58 (UTC) (edited on 2021-02-09 04:00 (UTC) by severach)

I see two types of missing libs. libavcodec and libavformat have many versions and use the one that matches the libs on your system. The versions I don't have all show errors and the version I do have (58) shows no errors. libawt, libjvm, and others are Java internals. Because you can have multiple versions of the jvm installed, these libs can't be placed where ldd can find them. Java must resolve these at runtime to the correct version. This looks like a bug in rebuild-detector for jre8 jdk8 because manually checking jdk8-openjdk jdk11 jre11 libs shows all the same missing libs but are not listed. A quick check with strace shows that libjvm is found just fine.

bartus commented on 2021-01-24 13:49 (UTC) (edited on 2021-01-24 13:55 (UTC) by bartus)

I've tested jre8 with modified rebuild-detector and there are some dangling symbols and missing shared object. This could be a source of problem whit one of my packages (openboard)

Could this missing stuff be fixed by including some extra deps?

jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/libdeploy.so
unresolved symbols: jws_g_list_length jws_g_list_nth_data native_trace
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/libavplugin-53.so
unresolved shared objects: libavcodec.so.53 libavformat.so.53
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/libavplugin-54.so
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/libavplugin-55.so
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/libavplugin-57.so
unresolved shared objects: libavcodec.so.53 libavformat.so.53 libx264.so.152 libvpx.so.4
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/libavplugin-ffmpeg-56.so
jdk8: /usr/lib/jvm/java-8-jdk/lib/amd64/libjawt.so
unresolved shared objects: libavcodec.so.53 libavformat.so.53 libx264.so.152 libvpx.so.4 libavcodec-ffmpeg.so.56 libavformat-ffmpeg.so.56

Google only finds single reference to jws_g_list_length referencing oracle community post suggesting archives for old java are corrupted...

Erus_Iluvatar commented on 2020-12-18 17:00 (UTC)

Hi, please don't set PKGEXT in you PKGBUILD : this overrides makepkg.conf in which I don't compress packages.

severach commented on 2020-07-08 16:10 (UTC) (edited on 2020-07-08 16:11 (UTC) by severach)

Bumping pkgrel will make everyone upgrade. No need to upgrade when all current installs are just fine. Also, if dropping JCE causes a problem I'd rather hear about it from new users than long time users who's everything suddenly breaks. The drawback of not changing pkgrel is that users who were having a problem won't get a version change to show that their problem is fixed.

aminvakil commented on 2020-07-08 07:07 (UTC)

Just out of curiosity and to be sure, you haven't bumped pkgrel in two latest changes becuase the final package hasn't changed and you have just changed how it downloads and stuff, am I right or was it because of something else?

kristianjgs commented on 2020-07-07 22:21 (UTC)

==> Validating source files with md5sums... jce_policy-8.zip ... FAILED jre-8u251-linux-x64.tar.gz ... Passed policytool-jre8.desktop ... Passed ==> ERROR: One or more files did not pass the validity check!

1 2 3 Next › Last »