Package Details: jdk 8u112-1

Git Clone URL: https://aur.archlinux.org/jdk.git (read-only)
Package Base: jdk
Description: Oracle Java Development Kit
Upstream URL: http://www.oracle.com/technetwork/java/javase/downloads/index.html
Keywords: java-environment-jdk java-openjfx java-runtime-headless-jre java-runtime-jre java-web-start-jre
Licenses: custom
Provides: java-environment=8, java-environment-jdk=8, java-openjfx=8, java-runtime=8, java-runtime-headless=8, java-runtime-headless-jre=8, java-runtime-jre=8, java-web-start=8, java-web-start-jre=8
Submitter: td123
Maintainer: Det
Last Packager: Det
Votes: 725
Popularity: 12.223757
First Submitted: 2011-08-27 17:56
Last Updated: 2016-11-11 16:08

Dependencies (15)

Required by (1000)

Sources (7)

Latest Comments

alaskanarcher commented on 2016-10-21 08:29

I am getting a series of "warning: could not get file information for usr/lib/jvm/java-8-jdk/..." where the ... are dozens of files in both bin and jre. Install appears to be working. Anyone else getting this?

goetzc commented on 2016-09-16 19:14

You can delete from install file: update-desktop-database, update-mime-database and xdg-icon-resource, as those updates are now performed by pacman hooks.

Det commented on 2016-08-24 14:48

700 votes <3.

I'd like to celebrate this with an update, but..

E: It was also apparently 5 years since first submitted. Damn.

XTREEMRAGE commented on 2016-07-14 09:57

Thanks for this package, keep it up :)

Det commented on 2016-07-13 17:22

You could try 'makepkg -L', or just makepkg in-and-of-itself.

m6w6 commented on 2016-07-13 05:55

Currently failing in package():

==> Starting package()...
-> Creating directory structure...
-> Removing redundancies...
-> Moving contents...
-> Fixing directory structure...
syntax error at (eval 1) line 1, near "."
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build jdk.

yaourt 1.8.1
pacman 5.0.1
libalpm 10.0.1

erkexzcx commented on 2016-04-26 19:10

I always need to perform this command when starting specific app via WEB:
sudo chown -R :wheel /etc/java*

Marcel_K commented on 2015-12-24 01:43

I stand corrected. And I know the previous ABI is still supported, but in the future this package should indeed correct the issue, not Oracle.

Det commented on 2015-12-23 23:30

You seem a little confused when you say that. I somehow missed that before, but these binaries are provided for whatever dependencies Oracle themselves chooses, that is, the ones in the widest circulation (used by Ubuntu).

So, if you're to rebuild your product for every new major dependency release, you're essentially dropping support for any distribution that uses the old version. Unlike things like libpng and libjpeg, GCC actually still provides the previous ABI (as per the announcment), and even if they were to drop it, it would be up to an AUR package to provide it for our distribution.

Marcel_K commented on 2015-12-12 19:48

According to the script in [1] the binaries should be recompiled. However, this package relies on precompiled binaries. Should this be escalated to Oracle or …?

[1] https://www.archlinux.org/news/c-abi-change/

Det commented on 2015-10-13 15:43

Maybe.

It wouldn't take much effort to add the sources, etc., but I'm not interested in introducing any complicated ARM-specific hacks in the build.

E: There's also a separate package: https://aur.archlinux.org/packages/jdk-arm

xdqi commented on 2015-10-12 15:24

Is there possible to add support for ARM architecture (a.k.a ArchARM).
Oracle provides JDK that runs on armv6h, armv7h and armv8h.

Det commented on 2015-07-18 18:40

Our own OpenJDK already includes this, so why not ('local_policy.jar' and 'US_export_policy.jar' in /usr/lib/jvm/java-8-openjdk/jre/lib/security/). It's apparently not included in Oracle JDK for legal reasons:

- https://www.archlinux.org/packages/extra/x86_64/jre8-openjdk-headless/files/
- http://www.eyrie.org/~eagle/notes/debian/jce-policy.html

veeti commented on 2015-07-17 17:25

Could you consider adding the unlimited crypto strength policies (http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html) to this package? They provide access to important ciphers like 256-bit AES and are required for some applications. I dare say that upstream is just plain wrong still shipping this separately in 2015, and this would be the responsible thing to do.

Det commented on 2015-07-11 07:53

You can, because the description "Oracle Java Development Kit" mentions it: https://aur4.archlinux.org/packages/?O=0&SeB=nd&K=java&outdated=&SB=v&SO=d&PP=250&do_Search=Go

I've been meaning to ask this, seeing how you typo some words, do you have a dyslexia?

Jristz commented on 2015-07-11 05:26

As you say "for the search function" as I thing that a java package need jave java as one of they keywords, if someone search for java using only keywords then will sure be apreciated the corect tagging, those arent anymore groups, they are keyword and therefor are key for search word and so need to be correctly seted.

Det commented on 2015-07-09 09:32

The keywords are meant for the search function and not really to pretify the package page.

Jristz commented on 2015-07-09 09:30

you coud add jdk and java to the keywords too?

truh commented on 2015-04-15 15:11

> jdk-8u45-linux-x64.tar.gz ... FAILED
never mind, did only happen the first time.

truh commented on 2015-04-15 15:10

==> Validating source files with md5sums...
jdk-8u45-linux-x64.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build jdk.

Det commented on 2015-03-03 21:17

E: Scratch that. Fixed.

Det commented on 2015-03-03 21:15

You download must be corrupt. Check your filesystem.

stevenhoneyman commented on 2015-03-03 21:12

policytool-jdk8.desktop ... FAILED
==> ERROR: One or more files did not pass the validity check!

BOHverkill commented on 2015-02-20 16:26

I clicked the false button, I am sorry :(

Det commented on 2015-02-20 06:40

BOHverkill, reason?

galaux commented on 2015-01-25 11:54

@ypoluektovich: thanks for your comment on the bug tracker. I forgot package "jdk" was about JDK 8 which I was not targetting yet anyway.

ypoluektovich commented on 2015-01-25 01:27

@Det: yep, both this package and jdk7 seem to have updated tzdata in their latest (current) versions. The previous versions of both these packages had old tzdata.

@galaux: commented in the bugtracker.

Det commented on 2015-01-22 22:02

I'm currently getting:

0 ✓ det@Archlinux ~/Downloads/tzupdater-1.4.9-2014i $ sudo java -jar tzupdater.jar -u
You have a later version than the embedded one.
1 ✗ det@Archlinux ~/Downloads/tzupdater-1.4.9-2014i $ sudo java -jar tzupdater.jar -V
tzupdater version 1.4.9-b01
JRE time zone data version: tzdata2014j
Embedded time zone data version: tzdata2014i

galaux commented on 2015-01-22 21:49

It just so happens someone opened this bug report [0] about this. I have been working on a "tzdata-java" which should also work for this Oracle JRE. I would need some testing on it – package available as specified on bug report. Feel free to install and check whether it fixes potential timezone issues you may have and report back on the bug tracker. Thanks!

[0] https://bugs.archlinux.org/task/42585

ypoluektovich commented on 2015-01-22 21:39

Java does not use tzdata, it has its own timezone files. Unfortunately, Oracle doesn't keep up with the changes, but at least they provide a tool[1] to update the TZ info. Unfortunately, these changes are currently lost on upgrade. Can we use this tool to patch the JDK during build?

[1]: http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html

Det commented on 2015-01-21 17:04

Fixed.

biloucat commented on 2015-01-21 16:50

in PKGBUILD,
# Fix .desktop paths is bugged:
after install, Exec and Icon fields are erroneous

frederik commented on 2015-01-21 16:06

Sorry, just quickly read the code. You are totally right.
Cheers

Det commented on 2015-01-21 12:04

It's not getting updated, there's just a message what's your current default, which I think makes more sense than to let people wonder why isn't this package doing anything.

frederik commented on 2015-01-21 12:01

Please do not update the archlinux-java defaults when upgrading. It should be up to the user to switch the defaults when upgrading.

Det commented on 2015-01-15 14:53

You're probably either using an old version of Yaourt, or your pacman is lower than 4.2.0:

$ makepkg --version | head -1
makepkg (pacman) 4.2.0

$ yaourt --version | head -1
yaourt 1.5

Det commented on 2015-01-15 14:50

You're probably either using an AUR tool that hasn't been updated for the arch-specific sources, or your pacman is lower than 4.2.0:

$ makepkg --version | head -1
makepkg (pacman) 4.2.0

$ yaourt --version | head -1
yaourt 1.5

dareTake commented on 2015-01-15 14:30

I'm having trouble with building the package.

==> Starting package()...
/tmp/yaourt-tmp-dare/aur-jdk/./PKGBUILD: line 72: cd: jdk1.8.0_25: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build jdk.

Det commented on 2014-12-24 15:32

Nervermind, the fix was easy. By adding '-v' (--verbose) to the curl line, it gives:

-> Downloading jdk-8u25-linux-x64.tar.gz...
[...]
> Cookie: "oraclelicense=a"

Manually, we get:

$ curl -LC - -b "oraclelicense=a" -O http://download.oracle.com/otn-pub/java/jdk/8u25-b17/jdk-8u25-linux-x64.tar.gz
[...]
> Cookie: oraclelicense=a

(quotes are lacking) So, instead of:

DLAGENTS=('http::/usr/bin/curl -v -LC - -b "oraclelicense=a" -O')

We need to use:

DLAGENTS=('http::/usr/bin/curl -v -LC - -b oraclelicense=a -O')

I'll report this elsewhere.

Det commented on 2014-12-24 15:20

It could be due to pacman 4.2.0. You're using that as well?

Manual download works:

$ curl -LC - -b "oraclelicense=a" -O http://download.oracle.com/otn-pub/java/jdk/8u25-b17/jdk-8u25-linux-x64.tar.gz

sl1pkn07 commented on 2014-12-24 10:38

download the tar.gz now broken again?

greetings

Det commented on 2014-12-05 17:00

8u25-2: brought back the bundled Oracle DB and VisualVM, and attempted to simplify the PKGBUILD.

Det commented on 2014-12-05 09:16

Oh, right. Thanks for the link. You were only talking about packaging the scripts, but leaving the libs be.

I'll fix that then.

E: Apparently, old PKGBUILDs are also found in:
- https://aur.archlinux.org/packages/ja/java8-oracle/PKGBUILD
- http://pkgbuild.com/git/aur-mirror.git/tree/java8-oracle/PKGBUILD

Det commented on 2014-12-05 09:05

Oh, right. Thanks for the link. You were only talking about packaging the scripts, but leaving the libs be.

I'll fix that then.

galaux commented on 2014-12-05 09:02

FYI, my suggestion is still available here https://github.com/galaux/java8-oracle

Det commented on 2014-12-04 19:11

Was meant to be provided by derby (https://aur.archlinux.org/packages/derby/), which I for some unrecallable reason made to replace that part of this package with. That's fine in essence, I think it's also what gallaux wanted, but it misses the whole lib directory, which I assume is what your troubles were about, too.

Guess I could pull the whole directory back, along with VisualVM. Don't take too much space even put together anyway..

hcz commented on 2014-12-04 18:48

I just spent few hours to figure out what happend with Java DB driver in my Netbeans ;)

Det commented on 2014-12-03 20:59

Kill me. I'm right here, kill me.

What of those did you need on your system?

hcz commented on 2014-12-03 20:57

"msg2 "Removing redundancies"
rm -r db/ jre/lib/fontconfig.*.{bfc,properties.src} jre/plugin/ jre/{COPYRIGHT,LICENSE,README,*.txt} lib/visualvm/ man/ja # lib/missioncontrol"

I'm gonna kill somebody...

Corubba commented on 2014-11-29 00:02

ttf-font is a meta package, provided by most (if not all) ttf-* packages like ttf-dejavu or ttf-liberation. It is used so packages don't need to depend on a specific ttf font package but just any ttf font. Install one of the ttf font packages and the dependency will be statisfied.

ac4r_g0 commented on 2014-11-28 23:50

What is the ttf-font dependency? There isn't package in the repos.

Marcel_K commented on 2014-11-25 20:22

And I think that the problem with packer is that it can't handle dynamically generated md5sums, like makepkg can.

Det commented on 2014-11-24 23:31

It's fine to flag for my part when the md5sums don't match, but naturally you should make sure you're not doing it unnecessarily.

Marcel_K commented on 2014-11-24 22:55

It built fine for me. Anyway, it's not out-of-date, so you shouldn't have flagged it like that anyway. Just leave a comment when you're sure the PKGBUILD or one of the accompanying files is wrong.

mitch_feaster commented on 2014-11-24 22:46

Hmm I flagged this as out-of-date but maybe it's fine... The md5 check for jdk-8u25-linux-x64.tar.gz fails when I try to install it with packer, but I can download and install it with makepkg just fine...

Carlinix commented on 2014-11-17 12:50

I recommend to include a configuration file like this:
echo -e "/usr/lib/jvm/java-8-jdk/jre/lib/amd64/\n/usr/lib/jvm/java-8-jdk/jre/lib/amd64/server/" > /etc/ld.so.conf.d/oracle-jdk.conf to solve this kind of problem:

scilab-bin:
libjava.so => not found
libverify.so => not found
libjvm.so => not found
libjava.so => not found
libverify.so => not found
libjvm.so => not found
libjava.so => not found
libverify.so => not found
libjvm.so => not found
libjava.so => not found
libverify.so => not found
libjvm.so => not found
libjava.so => not found
libverify.so => not found
libjvm.so => not found

Det commented on 2014-10-29 00:31

Reverted. It's generally not a good practice to use conflicting names with binaries from packages as important as util-linux. It's even worse to expect package maintainers to accommodate for these kinds of personal tweaks.

Det commented on 2014-10-28 21:14

I noticed that too, and was planning to secretly revert the line in a few days or so. :)

I assume he thought it was simpler, and didn't want to use an alias.

Marcel_K commented on 2014-10-28 21:13

Why did you install perl-rename as rename? It's just a [community] package that installs /usr/bin/perl-rename.

Det commented on 2014-10-28 21:10

Done. Thanks for reporting.

jleclanche commented on 2014-10-28 21:04

Ah, I see why; I have perl-rename installed under /usr/local/bin/rename.

A simple fix, if you're willing to do it, is to use /usr/bin/rename.

Det commented on 2014-10-28 21:04

You didn't accidentally modify the PKGBUILD?

jleclanche commented on 2014-10-28 21:02

This is broken for me.

.
==> Startar package()...
-> Creating required dirs
-> Preparing
syntax error at (eval 1) line 1, near "."
==> FEL: Ett fel uppstod i package().
Avbryter...
==> ERROR: Makepkg was unable to build jdk.

Det commented on 2014-10-16 06:50

The same way.

CPUnltd commented on 2014-10-16 04:46

if I'm using this package, how do I do a manual update equivalent to the process on the main news page?

Det commented on 2014-10-15 06:22

Yeah, I trust your Bash skills, too. :)

java.com has been updated for v8, and they provide "auto-download" links (no cookie flags), but only for JRE: https://www.java.com/en/download/manual.jsp

Marcel_K commented on 2014-10-14 22:26

And you'll have to change to first part of the MD5 checksum curl line to:

https://www.oracle.com/webfolder/s/digest/${pkgver}checksum.html

(you'll be able to shorten this a bit more).

zertyz commented on 2014-10-14 19:04

jdk 8u25 is out and required by some internet bankings...

KingYes commented on 2014-10-13 19:21

Thanks @galaux and @Det !

Det commented on 2014-10-13 16:14

I'm not sure you got that. What I'm referring to there is that the problem he's having was already explained by galaux for everybody, and I will surely be fixing it later on when I get the time to do so.

Commander commented on 2014-10-13 16:11

@Det

Um the dependencies are wrong no? It should now be changed as galaux said.
change your "java-runtime" providing package dependency
from "java-common" to "java-runtime-common"

Are the other things with JAVA_HOME etc fixed in this pkgbuild?

Det commented on 2014-10-13 15:16

I surely can, see the explanation from galaux just before your comment.

KingYes commented on 2014-10-13 06:42

I can't upgrade my system cuz this package:

:: Replace java-common with extra/java-runtime-common? [Y/n] Y
resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: jdk: requires java-common


Can you fixes it for me?

galaux commented on 2014-10-12 20:00

As previously reported, package "java-common" is now gone in favor of "java-runtime-common" and "java-environment-common".

@users: once this very package is updated, you will be able to build and install it. Please note that a news item was posted (https://www.archlinux.org/news/java-users-manual-intervention-required-before-upgrade/) that provides 3 quick commands to prevent you from getting a "file conflict" error during the next pacman upgrade.

Please see our Java wiki page for info, and forum, IRC, Mailing lists for help.

@maintainer: you will need to:
- change your "java-runtime" providing package dependency from "java-common" to "java-runtime-common"
- add dependency "java-environment-common" to your "java-environment" providing packages

Changelog:
- Links from /usr/bin now belong to one of the mentioned "common" packages (fixes FS#41883)
- Links from /usr/bin point at /usr/lib/jvm/default/bin/* and thus do not use JAVA_HOME nor script /usr/lib/java-common-wrapper (prevents incorrect Java path detection for many build or run scripts). As a side effect, forcing a Java runtime by setting JAVA_HOME is now NOT supported anymore.

This should be all. Please have a look at official OpenJDK packages from extra for reference. "install" scripts for OpenJDK packages have also been revamped for nicer integration but without any consequence on other packages. These could easily be customized (or even taken "as is") for your own "install" scripts.

galaux commented on 2014-10-12 19:59

As previously reported, package "java-common" is now gone in favor of "java-runtime-common" and "java-environment-common".

@users: once this very package is updated, you will be able to build and install it. Please note that a news item was posted (https://www.archlinux.org/news/java-users-manual-intervention-required-before-upgrade/) that provides 3 quick commands to prevent you from getting a "file conflict" error during the next pacman upgrade.

Please see our Java wiki page for info, and forum, IRC, Mailing lists for help.

@maintainer: you will need to:
- change your "java-runtime" providing package dependency from "java-common" to "java-runtime-common"
- add dependency "java-environment-common" to your "java-environment" providing packages

Changelog:
- Links from /usr/bin now belong to one of the mentioned "common" packages (fixes FS#41883)
- Links from /usr/bin point at /usr/lib/jvm/default/bin/* and thus do not use JAVA_HOME nor script /usr/lib/java-common-wrapper (prevents incorrect Java path detection for many build or run scripts). As a side effect, forcing a Java runtime by setting JAVA_HOME is now NOT supported anymore.

This should be all. Please have a look at official OpenJDK packages from extra for reference. "install" scripts for OpenJDK packages have also been revamped for nicer integration but without any consequence on other packages. These could easily be customized (or even taken "as is") for your own "install" scripts.

Det commented on 2014-09-11 16:36

Yea.:

1) # rm -r /usr/share/licenses/jdk/
2) install 8u20-2

edoantonioco commented on 2014-09-11 16:34

I cant update it.

:: ¿Continuar con la instalación? [S/n] s
(1/1) verificando llaves en el llavero [####################################################] 100%
(1/1) verificando la integridad de los paquetes [####################################################] 100%
(1/1) cargando los archivos del paquete... [####################################################] 100%
(1/1) verificando conflictos entre archivos [####################################################] 100%
error: error al realizar la transacción (archivos en conflicto)
jdk: /usr/share/licenses/jdk existe en el sistema de archivos
Ocurrieron errores, no se actualizaron paquetes
==> AVISO: Sus paquetes se han guardado en /tmp/yaourt-tmp-eduardo
==> ERROR: no se puede actualizar

Should I delete that file?

Det commented on 2014-09-10 02:26

I responded in the mailing thread. Let's continue that in there and stop inadvertently provoking disagreements with phrases like "this is sick" and "endless discussion", all right?

- https://mailman.archlinux.org/pipermail/aur-general/2014-September/029499.html

Det commented on 2014-09-10 02:25

I responded in the mailing thread (https://mailman.archlinux.org/pipermail/aur-general/2014-September/029497.html). Let's continue that in there and stop inadvertently provoking disagreements with phrases like "this is sick" and "endless discussion", all right?

russo79 commented on 2014-09-10 01:28

@Det
I'm not sure of your interpretation of the naming rules.
After reading the preamble of the OpenJDK bylaws [1], and giving a look at their [2] website, I would interpret OpenJDK more as a "vendor" than a project name.

This "vendor" provides several projects, one of them named JDK 8 [3].

Although I may be wrong, this makes me think that my interpretation of "java<majorversion>-<vendor>" as naming convention is more appropriate than "java-<major version>-<project name>" .

I would be grateful if you could you give a look at their site just to check if I might have a point here. :)

Personally, I really don't care about these naming issues, the only thing that I wanted was for the JDKs/JREs to respect the new packaging guidelines and make usage of "java-common".

However, after reading the comments being posted on some of the JDK/JREs packages as well as the requests and comments on [aur-requests] and [aur-general], I would like to avoid this situation to become a endless discussion (we have enough of them in the FOSS ecosystem).


[1] http://openjdk.java.net/bylaws
[2] http://openjdk.java.net/
[3] http://openjdk.java.net/projects/jdk8/

Jristz commented on 2014-09-09 22:22

Ok for the naming issue I brig this thread:
https://mailman.archlinux.org/pipermail/aur-general/2014-September/029497.html

Boris-B commented on 2014-09-09 19:01

I think that there is a problem with the licenses. This caused me to have file conflicts when updating this package.

It looks like license files are both installed in /usr/share/licenses/jdk and /usr/share/licenses/java8-jdk but only the files in /usr/share/licenses/java8-jdk are tracked.

Here's what I have:

[boris@boris-desktop licenses]$ pacaur -Ql jdk | grep licenses 0
jdk /usr/share/licenses/
jdk /usr/share/licenses/java8-jdk/
jdk /usr/share/licenses/java8-jdk/COPYRIGHT
jdk /usr/share/licenses/java8-jdk/LICENSE
jdk /usr/share/licenses/java8-jdk/THIRDPARTYLICENSEREADME-JAVAFX.txt
jdk /usr/share/licenses/java8-jdk/THIRDPARTYLICENSEREADME.txt
jdk /usr/share/licenses/jdk
[boris@boris-desktop licenses]$ ls /usr/share/licenses/jdk 0
COPYRIGHT LICENSE THIRDPARTYLICENSEREADME-JAVAFX.txt THIRDPARTYLICENSEREADME.txt

Det commented on 2014-09-09 16:10

Well, because the path for OpenJDK was chosen as '/usr/lib/jvm/java-8-openjdk' (java-<major version>-<project name>), I simply preferred making mine 'java-8-jdk' (not 'java-8-oracle'). The actual name of the project is 'JDK', not 'Oracle JDK', and it also creates consistency with the man pages:

$ man java-openjdk8
$ man java-jdk8

Instead of:

$ man java-openjdk8
$ man java8-oracle

Which also made me change the following dependencies:

- java-runtime-headless-oracle
- java-runtime-oracle
- java-web-start-oracle
- java-environment-oracle

to:

- java-runtime-headless-jre
- java-runtime-jre
- java-web-start-jre
- java-environment-jdk (a JDK component)

Even if all of those end up being '-jdk' for simplicity, I'd still prefer that setup, than the whole excessive "Oracle" tagging.

> By the way, shouldn't jdk-devel and jre-devel also be changed to make usage of the java-common package?

I suppose you didn't have a look. They both do.

russo79 commented on 2014-09-09 10:41

@Jristz
Nowhere in the Java Package Guidelines [1], it is specified that the package JREs/JDKs must follow a given name convention.
Also "the guy in jdk7" as you named it just said that he'd *like* to follow the convention used by the packages provided officially :)
(which seams to be "<jdk/jre><majorversion>-<vendor>").


@Det
Although you are free to follow the naming convention you want (since officially there is none), it would be nice for all the JDKs and JREs provided both in AUR and on the official repositories to follow the same naming convention.

What do you think about renaming your jdk and jre packages to jdk8-oracle and jre8-oracle respectively?
To ease the transition you could even add a "provides" entry in your PKGBUILDs so that packages depending on this one can keep working without having their PKGBUILDs modified.
I know this is a bit PITA, but what do you think?

By the way, shouldn't jdk-devel and jre-devel also be changed to make usage of the java-common package?


[1] https://wiki.archlinux.org/index.php/Java_Package_Guidelines

Jristz commented on 2014-09-08 21:00

Is not the new Java guideliness say that this package need to be namd jdk-oracle (and the dev: jdk-devel-oracle)?

The guy in jdk7 is claiming that and the request on jdk7-oracle -> jdk7 claim that the new scheme name is jdk7-oracle and this package need to be changed too.

Det commented on 2014-09-04 10:40

You people.

@klingt.net, yes, as I already told you, the old $JAVA_HOME from /etc/profile.d/jdk.sh (without rebooting) was the problem.

@lots0logs, yes, as I already told you, the upgrade process is:
1) # rm -r /usr/share/licenses/jdk/
2) install 8u20-2

klingt.net commented on 2014-09-04 09:13

@simonorono

I switched back to jdk8-openjdk from extra. But I think the problem was a wrong $JAVA_HOME, the old value was /opt/java and the new one is /usr/lib/jvm/default. This was changed due to the java-common update and maybe I overlooked the message to logout/login, so the old value was still present.

lots0logs commented on 2014-09-04 03:25

I got this error when I attempted to update:

error: failed to commit transaction (conflicting files)
unable to --force directory-file conflicts
jdk: /usr/share/licenses/jdk exists in filesystem
Errors occurred, no packages were upgraded.

For a quick fix I edited the PKGBUILD by removing the line that attempts to create a symlink over the /usr/share/licenses/jdk directory (that already existed on my system.)

Det commented on 2014-09-03 20:35

It's automatically set by /etc/profile.d/jdk.sh or /etc/profile.d/jre.sh (to let apps know where Java is located).

/etc/profile.d/jre.sh is now owned by 'java-common' and shouldn't be installed by Java packages anymore.

Anonymous comment on 2014-09-03 20:33

@klingt.net @det

this is embarrassing, I just rebooted my PC and everything is fine

BTW:
-I tried archlinux-java fix and it didn't worked
-I never set JAVAHOME

Det commented on 2014-09-03 20:15

Uhh.. so what happens when you run:

# archlinux-java fix

Also, what's the version of your 'java-common' (should be 1-6), and the output of:

$ archlinux-java status

I just retried the upgrade, and I still get the same /usr/bin/java (-> /usr/lib/java-common-wrapper) content, which is:

#!/bin/bash
exec "${JAVA_HOME:-/usr/lib/jvm/default}/bin/${0##*/}" "$@"

E: It might also be enough to just "unset JAVA_HOME", "source /etc/profile" or reboot. Any of those to update the JAVA_HOME variable.

Det commented on 2014-09-03 20:09

Uhh.. so what happens when you run:

# archlinux-java fix

Also, what's the version of your 'java-common' (should be 1-6), and the output of:

$ archlinux-java status

I just retried the upgrade, and I still get the same /usr/bin/java (-> /usr/lib/java-common-wrapper) content, which is:

#!/bin/bash
exec "${JAVA_HOME:-/usr/lib/jvm/default}/bin/${0##*/}" "$@"

Det commented on 2014-09-03 20:08

Uhh.. so what happens when you run:

# archlinux-java fix

Also, what's the version of your 'java-common' (should be 1-6), and the output of:

$ archlinux-java status

I just retried the upgrade, and I still get the same /usr/bin/java(-common-wrapper) content, which is:

#!/bin/bash
exec "${JAVA_HOME:-/usr/lib/jvm/default}/bin/${0##*/}" "$@"

klingt.net commented on 2014-09-03 19:58

@simonorono
confirmed, same here

Anonymous comment on 2014-09-03 17:10

After the last update, when I try to run Java I get the following:

/usr/bin/java: line 2: /opt/java/bin/java: No such file or directory

Anonymous comment on 2014-09-03 14:01

@Det will that must be done on every update?

Det commented on 2014-09-03 13:43

@simonorono, I just told how to fix that?:

1) # rm -r /usr/share/licenses/jdk/
2) install 8u20-2

Anonymous comment on 2014-09-03 13:41

I'm getting this:

error: failed to commit transaction (conflicting files)
jdk: /usr/share/licenses/jdk exists in filesystem
Errors occurred, no packages were upgraded.

BunBum commented on 2014-09-03 11:37

Sorry, my mistake... :-/

Det commented on 2014-09-03 11:29

@BunBum, the syntax is '-version':
└┌(%:~/Desktop)┌- java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

@frederik, I just told you, if you would have scrolled just a couple of comments down: to allow parallel installations, which I was asked to support now that Guillaume implemented that possibility through 'java-common' (OpenJDK, JRE7, etc.).

@madmack, apparently you're going to have to first remove that folder manually, as Pacman refuses to (even with --force) to replace a directory with a file (symlink).

BunBum commented on 2014-09-03 10:21

And if you remove /usr/share/licenses/jdk from the filesystem you get my error :-/ ("Could not create the Java Virtual Machine")

frederik commented on 2014-09-03 10:20

and if I exclude java-common I get this one:

jdk: /usr/share/licenses/jdk exists in filesystem

frederik commented on 2014-09-03 10:16

Why does this depends on java-common?
I'm getting errors when installing java-common

The links "/usr/lib/jvm/java-default-runtime“ and „/usr/lib/jvm/default-runtime“ can not be created.

BunBum commented on 2014-09-03 07:26

Updated to jdk 8u20-2 and getting now following error:

me@foo /opt/java/jre/lib/security % java -v
Unrecognized option: -v
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

madmack commented on 2014-09-03 06:58

getting this error when trying to update today:

jdk: /usr/share/licenses/jdk exists in filesystem

Det commented on 2014-09-03 01:53

@sl1pkn07, fixed that as well.

E: Also, you could probably have a bit more careful look on things before adding a new comment. Thanks.

sl1pkn07 commented on 2014-09-03 01:30

please fix your backup=() array

need move after #variables and before source=()

greetings

Det commented on 2014-09-03 01:27

@sl1pkn07, fixed that as well.

sl1pkn07 commented on 2014-09-03 01:09

yes. i know

Det commented on 2014-09-03 01:04

8u20-2: support 'archlinux-java' (extra/java-common).

See: https://wiki.archlinux.org/index.php/Java#Switching_between_JVM

sl1pkn07 commented on 2014-09-03 01:02

-> Moving stuff in place
install: cannot stat 'jre/lib/etc/java-//jvm.cfg': No such file or directory

Det commented on 2014-08-27 18:36

Yes, I'll see when I have time. Thanks.

russo79 commented on 2014-08-25 08:29

Maybe this package can be updated and jdk8-oracle [1] can be merged into this one.

[1] https://aur.archlinux.org/packages/jdk8-oracle/

russo79 commented on 2014-08-25 08:17

For what it's worth, https://aur.archlinux.org/packages/jdk8-oracle/ is already packaged according to the new guidelines.


mtorromeo commented on 2014-08-25 08:08

Please update the package according to the new Arch Java guidelines: https://wiki.archlinux.org/index.php/Java

Marcel_K commented on 2014-06-10 11:40

If you look at the PKGBUILD, you'll notice that a 64-bit tarball is downloaded when the target system is x86_64.

netz commented on 2014-06-10 07:46

I just noticed this PKGBUILD uses the i586 java tarball... does this make a difference in practice? I'm using arch x86_64

Det commented on 2014-05-30 13:56

Assumably yes, if that's what the -compat packages are doing.

vibee commented on 2014-05-30 13:52

Can't we set different installation paths for the JVM and JDK?

Det commented on 2014-05-30 13:39

In simple terms, both packages install same files, so that's why they're in conflict.

vibee commented on 2014-05-30 13:36

Why is this package in conflict with jdk7-openjdk? I would like to install JKD8 and JDK7.

Det commented on 2014-05-15 11:58

It can happen from time to time that Arch pisses me off and I start exclusively using Windows, which doesn't give a crap about Unix permissions.

So there.

liujed commented on 2014-05-15 01:40

Please fix the file permissions on the package's files. Everything in the tarball has mode 777.

Det commented on 2014-04-27 18:58

/opt/java/jre/lib/security/java.policy is now also backed up automatically.

Det commented on 2014-04-27 13:41

That's what workaround, not a fix. The profile.d scripts are supposed to include non-standard locations in your path.

But to make this work I'd need you to do what I asked you in my last reply.

ansidev commented on 2014-04-27 13:38

@Det: I found the way to fix the error, just run command:
sudo ln -s '/opt/java/bin/java' '/usr/bin/java'

rdjack21 commented on 2014-04-26 03:00

Just wanted to say thank you..

Det commented on 2014-04-25 08:37

Enabled by default: permission java.awt.AWTPermission "accessClipboard"
- https://blogs.oracle.com/kyle/entry/copy_and_paste_in_java

Det commented on 2014-04-25 08:07

Really? Could you post your /etc/profile in Pastebin? What happens, if you "$ source /etc/profile.d/jdk.sh" directly? Is $JAVA_HOME unset or is it just the apps that aren't working?

ansidev commented on 2014-04-25 03:28

Nothing changed :(

Det commented on 2014-04-24 13:21

Seems like at least "/etc/profile.d/jdk.sh" is not sourced automatically for you. I don't know, if anything else from /etc/profile.d/* is either, but a simple "$ source /etc/profile" should work.

0 ✓ det@Archlinux ~ $ echo $JAVA_HOME
/opt/java/jre

ansidev commented on 2014-04-24 09:53

If I install Open JDK, there are no problems.

ansidev commented on 2014-04-24 09:52

I cannot start Intellij IDEA or eclipse.
For example: I received a message "No JDK found. Please validate either IDEA_JDK, JDK_HOME or JAVA_HOME environment variable points to valid JDK installation." when I try to run Intellij IDEA.
And java is not default application for .jar file. How to fix them?
My ArchLinux is a fresh system.

Det commented on 2014-04-24 02:13

Meaning?

ansidev commented on 2014-04-24 01:50

Package not working. Java system variables not configured correctly.

denisfalqueto commented on 2014-04-16 03:11

JDK 8u5 is out :)

Det commented on 2014-04-08 14:24

Not really. It actually seems like you (or whoever told you about this) have misunderstood me in pretty much everything you just brought up.

First of all, I'm a bit puzzled with your statement of you "always knowing" I've had some kind of resentment towards you, which you cannot explain. I can not either. I have no idea what you are talking about. You release Open Java for Arch and I release Oracle Java in here. I was a real moron, if I resented you for that. There is absolutely nothing personal to it.

Also, I'd like to believe that leaving _any_ unnecessary "bitterness" at a remote location is _the_ best thing you _can_ do (the mailing list rules don't allow this anyway). But that's not the case. When I talk about you not having "a clue" I was talking about packaging Oracle JDK in our repos, which is prevented by the removal of the DLJ, which in turn is the whole reason I ever got to maintain this thing.

And I'm _definitely_ not bitter at that.

galaux commented on 2014-04-08 09:02

Hello Det,
I think you misunderstood me in the email you cite, I am just bringing the point to the ML about shipping OpenJDK without Icedtea.
I have always suspected you had some kind of resentment towards me that I cannot explain. Please feel free to email me privately if you would like to calmly sort human things out. Also please do not make such bitter statements on a remote place – not everybody is notified about this package' comments – but instead do post to arch-general in order to communicate.
Hopes this can peacefully clarify the situation.
Guillaume

Det commented on 2014-04-08 02:24

I actually found it amusing to see our second maintainer of OpenJDK not to have a clue about packaging this thing in our repos (option #3 in [1]), which has been impossible since August 2011[2], or the existance of the Java Snapshots[3], to which end I've provided packages in the AUR since September 2012 (jre-/jdk-devel).

[1] = https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026082.html
[2] = http://www.h-online.com/open/news/item/Oracle-retires-licence-for-distributing-its-Java-with-Linux-1332835.html
[3] = http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026973.html

Well. In a similar way I suppose our devs might smirk at me for trying to bump a 7-1 with 7u1-1. Or to do what I did now, but not report the Pacman 'bug' upstream. They're really doing a good job trying to bring us that long-waited OpenJDK 8.

FernandoBasso commented on 2014-03-29 11:20

This package is very important. Keep up the good work.

Det commented on 2014-03-22 12:13

I'm sure someone will create one even, if I don't care about that.

vnoel commented on 2014-03-22 10:21

Hi, I don't know if it is the right place to ask for that but it would be great to have a jdk-compat as with jdk7 and jdk6 :)

Det commented on 2014-03-21 13:34

What he said.

Marcel_K commented on 2014-03-21 12:05

And if you only want compression disabled of *this* package, you can always add

PKGEXT='.pkg.tar'

in the PKGBUILD of this package.

Det commented on 2014-03-20 16:29

Hmm, well, you removed your good question, but I'm gonna answer here anyway even, if already have.

The answer is: yes, we can speed up the compression like it used to be.

To have PKGEXT='pkg.tar' for all packages:
$ sudo sed -i "s/PKGEXT=.*/PKGEXT='.pkg.tar'/" /etc/makepkg.conf

And to revert that:
$ sudo sed -i "s/PKGEXT=.*/PKGEXT='.pkg.tar.xz'/" /etc/makepkg.conf

But clearly you should just acquaint yourself with /etc/makepkg.conf. It's got a lot of goodies.

E: The Wiki's good too: https://wiki.archlinux.org/index.php/Makepkg#Create_uncompressed_packages.
People like me, graysky and Kynikos spend quite a lot of time editing it, actually.

Det commented on 2014-03-20 16:23

Hmm, well, you removed your good question, but I'm gonna answer here anyway, even if already have.

The answer is: yes, we can speed up the compression like it used to be.

To have PKGEXT='pkg.tar' for all packages:
$ sudo sed -i "s/PKGEXT=.*/PKGEXT='.pkg.tar'/" /etc/makepkg.conf

And to revert that:
$ sudo sed -i "s/PKGEXT=.*/PKGEXT='.pkg.tar.xz'/" /etc/makepkg.conf

But clearly you should just acquaint yourself with /etc/makepkg.conf. It's got a lot of goodies.

ryenus commented on 2014-03-20 13:10

thanks for being the pioneer to make this package, can we skip package compression? it really slow down the installation process, especially for my poor old thinkpad.

Det commented on 2014-03-19 00:57

And here I was hoping to get rid of those.

Just now made you switch, though?

Zombifier commented on 2014-03-19 00:45

Should JDK conflict with java-runtime=7 and java-environment=7 as well? Currently pacman fails to replace jdk7-openjdk automatically.

Det commented on 2014-03-18 19:55

Updated to Java SE 8: https://blogs.oracle.com/java/entry/java_se_8_is_now

Made it a 8u0, so we can have 8u1, 8u2, etc. That was the mistake in the 7 series, as Pacman considers 7u1-1 a downgrade from 7-1.

Det commented on 2014-03-18 19:02

OMG. Java 8 is here already.

Det commented on 2014-03-16 14:59

We'll see how the Stack Overflow thread evolves: http://stackoverflow.com/a/10959815/1821548

E: Seems like this was the first guy to come up with the "--header" workaround: http://blog.kdecherf.com/2012/04/12/oracle-i-download-your-jdk-by-eating-magic-cookies/. For the longest time I thought it was one of our own guys.

Quite funny and informative actually.

Det commented on 2014-03-15 20:56

We'll see how the Stack Overflow thread evolves: http://stackoverflow.com/a/10959815/1821548

Det commented on 2014-03-15 19:20

Oracle apparently changed their fantastic license agreement method once again.

That change originally dates back two years (March 2012), which made me include the DLAGENTS override.

ashwin_cse commented on 2014-03-15 06:57

"$makepkg -s" does not get the jdk tar file, because oracle wants the user to accept license agreement before you can get the jdk tar file. So when i do a makepkg -s it downloads a html file (which wrongly states as jdk...tar.gz, but it is actually a html file) which states that this download is not permitted and i need to accept the license agreement before i can download.

Det commented on 2014-02-24 05:16

Removed "PKGEXT='.pkg.tar'" due to a request of having your own way through makepkg.conf.

Det commented on 2014-02-12 15:32

Ok, well the phrasing was a bit misleading, since it's not about the size or the unreliability of the Oracle servers that the download doesn't work. So it's not like an "improvement", it's actually the only way to do it.

Then about the PKGEXT, I've actually set it in quite a lot of places, and at times have thought about removing it from all of them (just because I can obviously set it myself), but people never complained so I never bothered. The initial argument I think was something like 'this thing is never provided to anybody, so a as-fast-as-possible install is preferable'.

But compression should, of course, be done like you like it to be done. Sure makes a lot more sense.

hefeweiz3n commented on 2014-02-12 15:23

As I stated: I know why DLAGENTS is in there, I remember the times when it wasn't... However the PKGEXT is definitely something where the user setting should take preference. On my laptop I too have compression disabled in /etc/makepkg.conf as it takes too long, however when building on said server for distribution on computers managed by me I need it. So it would be much appreciated if you could in fact remove it and set it locally on your computers according to your needs (which is in my opinion also the much cleaner version than setting it in a single package).

Thanks in advance!

Det commented on 2014-02-12 12:01

I agree it's not nice to override the DLAGENTS, but if you actually tried removing it you'll see why it's there.

hefeweiz3n commented on 2014-02-12 08:06

Please remove PKGEXT from the PKGBUILD.

If people don't want to compress locally built backages they can set it in their makepkg.conf. For people like me, who build the package on a fast machine and then distribute it to their computers via internt compression is necessary and it it always a pain in the butt to have to comment this out manually. It is also not nice to override user settings (In the case of the download agent I can however understand it with the big source package size and as I know the oracle download servers to be a bit unreliable).

Det commented on 2014-02-07 16:58

Took a while, but the dependency's finally fixed.

'Atk'[1] was pulled in as a dependency of 'classpath'[2], which made the reporter think that classpath should be required. After some discussion we found out that not only was 'atk' the real dependency, but this package doesn't require it at all.

So, even if you don't use OpenJDK[3], atk will still be installed, but it's required by things like GTK+ 2/3 anyway, so few will care.

[1] = https://www.archlinux.org/packages/extra/x86_64/atk/
[2] = https://www.archlinux.org/packages/community/x86_64/classpath/
[3] = https://www.archlinux.org/packages/extra/x86_64/jdk7-openjdk/

Det commented on 2014-01-31 21:36

Just to fill you in on this, we had a little discussion with Alex and he's decided to re-open the bug: https://bugs.archlinux.org/task/38567

His original idea was that since NetBeans continued to work even with the dependency he assumed everybody would be happy. But then when I asked him about it he agreed that if it really was unnecessary, then indeed it should be reverted.

We'll see what the original reporter has to say.

bigcajun commented on 2014-01-31 14:24

I agree with you. Not sure why the dependency was added to NetBeans. NetBeans runs fine for me without "classpath" installed. I haven't looked at all the details, but I think this package provides all the stuff that's in "classpath" so someone with this package installed shouldn't need "classpath" installed anyway. I added classpath to the provides list and rebuilt so that updating NetBeans wouldn't require me to also install classpath. I guess that's more of a hack than the real solution.

Maybe the person that filed the bug has a broken JDK (i.e. not this one)? It wasn't stated in the bug report what the Java environment (or which java packages) were installed.

Det commented on 2014-01-31 12:18

I'm not sure about this. (At least) for me NetBeans works just fine even with just 'jre7-openjdk', so the whole idea that NetBeans wouldn't even run, if you hadn't installed Classpath seems kinda crazy: https://bugs.archlinux.org/task/38567

And what's even crazier is that it actually went through. I removed both ~/.netbeans/ and ~/.cache/netbeans/ just in case and the EULA works too.

bigcajun commented on 2014-01-31 03:49

The NetBeans package recently added a dependency on the "classpath" package. Unless I am mistaken, having Oracle's JDK installed fulfills all of the NetBeans package needs. Might I suggest this package be updated to add "classpath" to the "provides" line in PKGBUILD? What I'm getting at is there doesn't seem to be a need to install the "classpath" package if you have this JDK package installed.

Det commented on 2014-01-05 18:42

@selaux, so it does, huh?

selaux commented on 2014-01-05 13:30

Why does jre7 provide /usr/bin/java and this package doesn't?

Det commented on 2013-11-02 08:57

Well. Yes.

donniezazen commented on 2013-10-31 06:19

I just wanted to make sure as long as I have jdk installed I will not need jre. Am I right?

Det commented on 2013-10-18 20:38

@nicoulaj, added.

Det commented on 2013-10-18 16:38

Sorry.

philanecros commented on 2013-10-17 06:57

Would you please add support for armv6h and armv7h?

Oracle's release support these 2 archtypes.

nicoulaj commented on 2013-10-12 18:40

Can you add a desktop entry for Mission Control ?

student975 commented on 2013-09-14 09:19

Is it a moment to downgrade? I use elasticsearch/lucene :)

https://issues.apache.org/jira/browse/LUCENE-5212

joschi commented on 2013-09-11 18:24

Updated PKGBUILD for Oracle Java 7u40: https://github.com/joschi/AUR/blob/1abd6f001510d26338fb0ad45a1e659b0cffde37/jdk/PKGBUILD

aloiscochard commented on 2013-09-11 09:16

511ea34e4a42955bc03c28afa4b8f6cf jdk-7u40-linux-x64.tar.gz

Det commented on 2013-08-15 17:19

I blame no one. It's human to make mistakes :).

Anonymous comment on 2013-08-12 11:07

Apologies - flagged out of date by mistake. Blame my daft fat fingers and lack of sleep :c

Det commented on 2013-07-02 23:33

Jesus fucking Christ..

frio commented on 2013-07-02 22:51

Not so much out of date, but I don't really know how AUR works that well and wanted to flag this as broken -- line 53 of the PKGBUILD, the "exit" probably shouldn't be there ;)

Det commented on 2013-05-21 08:26

That's what it already is, my dear..

nepjua commented on 2013-05-21 00:14

jdk-7u21-linux-x64.tar.gz md5sum 3ceef66377b6d87144b802960f5e715b

nepjua commented on 2013-05-20 23:48

x86_64 md5sum d9df35914b5b6c082d5619196f353e21

Det commented on 2013-05-12 10:52

Don't be :D. Happens to me all the time as well.

FernandoBasso commented on 2013-05-12 10:27

Sorry, I accidentally flagged the package out of date and can't undo the action. I'm really sorry.

Det commented on 2013-04-23 13:01

Our magnificient corporation has put its entire strategical unit to work and afters tens of thousands of man-hours they all agreed to come to one conclusion: their future was at stake.

This required rapid actions and their stock was already beginning to fall. They all knew what had to be done and there wasn't much time to it. The entire company rushed into this small room, pushed forward the janitor they considered good cannon fodder and as he pressed the button, silence settled in. It was over. Android phones were already announcing the victory.

So we need the --header flag again.

gyurman commented on 2013-04-23 06:27

Error have in md5sum jdk-7u21-linux-x64.tar.gz

Det commented on 2013-04-17 12:53

Done.

Jristz commented on 2013-04-17 05:06

Ok I found that derby-network-service is a rc file usin initscriptschema, you can make anithink to migrate this ti a service for systemd?
i think that call Exec=/path/to/a/script/that/run/derby and Stop/Halt=/path/to/stop/script and Restart=/Path/to/restart/script can by workaround for this task

Det commented on 2013-04-07 20:51

I kind of was thinking something else when I said that, lol.

Yeah, but I won't be adding it.

scorici commented on 2013-04-07 20:48

@Det 'lzop' must be in the makedepends=() because it won't build/create package without it, optdepends=() is for additional functionality

scorici commented on 2013-04-07 20:39

@Det 'lzop' must be in the makedepends=() because it won't build/create package without it, optdepends=() is for additional functionality

Det commented on 2013-04-07 20:05

Yea, I removed that once I realized it'd have to be included in the optdepends=().

scorici commented on 2013-04-07 19:08

-> Compressing package...
/usr/bin/makepkg: line 1898: lzop: command not found
bsdtar: Write error
==> ERROR: Failed to create package file.
==> ERROR: Makepkg was unable to build jdk.
==> Restart building jdk ? [y/N]
==> ----------------------------
==>

makedepends=('lzop')

Det commented on 2013-02-19 06:03

Very well.

Anonymous comment on 2013-02-19 03:51

I found that without "libxslt" the WebView (from JavaFX2) doesn't work.

Det commented on 2013-02-02 04:10

Yes. And I just ate a dolphin and invented salt.

1) Not ever once have I heard a paste just "disappearing" from pastebin without the expiration time being left as such. In fact, it seems as if the default choice was "never"

2) This had nothing to do with dead-linking the "answer" and everything to do with just hiding the useless pacman output.

3) This has come up numerous times, ever since I separated jre from jdk over 3 months ago. Had either of you actually tried Googling the output or looking for it right here instead of wondering what just happened we wouldn't have needed this stupid discussion.

So just remember: searching for things you want to know helps you find them. I think everyone who has internets knows that.

Rulatir commented on 2013-02-02 00:32

Maybe it's because we've seen one too many a problem-solving thread where someone had posted *the perfect solution* on pastebin (because it had more than 30 LOC), and that pastebin entry had since expired?

Things *disappear* from pastebin. Everyone who has internets knows that.

Det commented on 2013-01-18 18:20

I can't figure out why you people keep posting LONG messages in here instead of using Pastebin!

Is it because of http://pastebin.com being inaccessible?

Nope...

Is it because you don't have internets?

Nope...

What is wrong with you!?!?!?!?!?!?!?

darose commented on 2013-01-18 16:04

Ah yes that worked. I had already tried pacman -Rd. Didn't know the 2nd "d" was needed.

Tnx for the help!

gabrielrcp commented on 2013-01-18 16:02

You can do
$ pacman -Rdd jre
and afterward install jdk.

This will uninstall jre ignoring all dependencies. This is not normally recommended but in this case it will be fine, since jdk will provide java-runtime.

darose commented on 2013-01-18 15:39

I can't figure out how to upgrade this package!

I previously had jdk and jre installed. I just upgraded jre. Now I'm trying to upgrade jdk.

[darose@daroselin jdk]$ sudo pacman -U jdk-7.11-1-x86_64.pkg.tar
loading packages...
resolving dependencies...
looking for inter-conflicts...
:: jdk and jre are in conflict (java-runtime). Remove jre? [y/N] y

Targets (2): jre-7.11-1 [removal] jdk-7.11-1

Total Installed Size: 224.27 MiB
Net Upgrade Size: 8.17 MiB

Proceed with installation? [Y/n]


OK, so it tells me there's a conflict, and that now jdk supercedes jre. Fine.

Proceed with installation? [Y/n] y
(1/1) checking package integrity [#############################################################################] 100%
(1/1) loading package files [#############################################################################] 100%
(1/1) checking for file conflicts [#############################################################################] 100%
error: failed to commit transaction (conflicting files)
jdk: /usr/share/licenses/jdk/COPYRIGHT exists in filesystem
jdk: /usr/share/licenses/jdk/LICENSE exists in filesystem
jdk: /usr/share/licenses/jdk/THIRDPARTYLICENSEREADME-JAVAFX.txt exists in filesystem
jdk: /usr/share/licenses/jdk/THIRDPARTYLICENSEREADME.txt exists in filesystem
Errors occurred, no packages were upgraded.


No good. Maybe I can just uninstall jre first?

[darose@daroselin jdk]$ sudo pacman -R jre
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: android-sdk: requires java-runtime
:: antlr2: requires java-runtime
:: ec2-api-tools: requires java-runtime
:: eclipse-wtp: requires java-runtime>=5
:: frostwire: requires java-runtime
:: javacc: requires java-runtime
:: jdk: requires jre
:: junit: requires java-runtime-headless
:: proguard: requires java-runtime
:: swt: requires java-runtime>=6


Nope. So then maybe I can uninstall jdk, and then re-install?

[darose@daroselin jdk]$ sudo pacman -R jdk
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: antlr3: requires java-environment
:: apache-ant: requires java-environment
:: eclipse: requires java-environment
:: eclipse-android: requires java-environment>=6
:: tokyocabinet-java: requires java-environment


Again nope!

How can I do this upgrade?!?!?!?!?

Det commented on 2013-01-15 14:12

@ryenus, because as I said ages ago I grew tired of waiting for two minutes for it to compress.

ryenus commented on 2013-01-15 14:10

why having `PKGEXT=".pkg.tar"`?

$ ll ~/.cache/aur/jdk-7.11-1-i686.*
... 225M ... .cache/aur/jdk-7.11-1-i686.pkg.tar
... 68M ... .cache/aur/jdk-7.11-1-i686.pkg.tar.xz

Having zipped packages would save much space for all cached packages.

hgabreu commented on 2012-12-22 01:50

Really?? Sorry then...
I just build, installed it and ran into the problem. Haven't even read the PKGBUILD :-/

Det commented on 2012-12-22 01:05

But I _have_ included it in the PKGBUILD, my friend.

hgabreu commented on 2012-12-22 00:44

I've had this issue: https://bugs.archlinux.org/task/18872
Solved it by creating the folder /etc/.java/.systemPrefs
Maybe you could include this on the PKGBUILD.

Also, documented here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4532628

hgabreu commented on 2012-12-22 00:43

I've had this issue: https://bugs.archlinux.org/task/18872
Solved it by creating the folder /opt/.java
Maybe you could include this on the PKGBUILD.

Also, documented here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4532628

marcinfa commented on 2012-12-21 20:10

Sorry I accidentally flag. I wanted to download the tarball.

marcinfa commented on 2012-12-21 20:09

Sorry I accidentally flag. I wanted to download the tar

Det commented on 2012-12-12 17:20

No it wasn't.

Anonymous comment on 2012-12-12 13:36

there is a typo in PKGBUILD, one zero before $minor

package() {
msg2 "Creating required dirs"
cd jdk1.$_major.0_0$_minor

right version

package() {
msg2 "Creating required dirs"
cd jdk1.$_major.0_$_minor

Det commented on 2012-12-04 10:38

It does.

JRE = 'java-runtime', 'java-runtime-headless', 'java-web-start'
JDK = 'java-environment'

I'm providing all these.

kevku commented on 2012-12-04 10:31

Should’nt this also provide jre? Quite a lot of packages seem to directly depend on jre.

Det commented on 2012-12-02 19:28

Again, there are alternative mirrors in the PKGBUILD.

Anonymous comment on 2012-12-02 17:42

I get the following error:

ERROR: Failure while downloading jdk-7u9-linux-x64.tar.gz
Aborting...
==> ERROR: Makepkg was unable to build jdk.

It makes no sense... since I've installed another packages from AUR with no problem. Some help will be appreciated.

Cheers.

Det commented on 2012-10-30 22:33

It's an aurget bug: https://aur.archlinux.org/packages.php?ID=51908, https://aur.archlinux.org/packages.php?ID=31933

Anonymous comment on 2012-10-30 22:16

Can not install this version, it stops here..:

==> Extracting Sources...
-> Extracting jdk-7u9-linux-x64.tar.gz with bsdtar
==> Entering fakeroot environment...
==> Starting package()...
-> Creating required dirs
-> Removing the redundancies
-> Moving stuff in place
-> Symlinking the plugin
-> Installing the scripts, confs and .desktops of our own
-> Tweaking the javaws .desktop file
==> Tidying install...
-> Purging unwanted files...
-> Compressing man and info pages...
-> Stripping unneeded symbols from binaries and libraries...
-> Removing empty directories...
==> Creating package...
-> Generating .PKGINFO file...
-> Adding install file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: jdk 7.9-2 (Tue Oct 30 23:14:02 CET 2012)
:: Discarding sources...
:: Installing package...
error: : package not found

JohnnyDeacon commented on 2012-10-30 21:25

Ok, solved

Det commented on 2012-10-30 15:04

Verifies fine here. Your download is corrupt.

You could try the alternative mirrors if it's server-sided.

JohnnyDeacon commented on 2012-10-30 14:36

I got this error while installing JDK

==> Making package: jdk 7.9-2 (Tue Oct 30 09:33:46 COT 2012)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving Sources...
-> Found jdk-7u9-linux-x64.tar.gz
-> Found derby-network-server
-> Found derby-network-server.conf
-> Found java-monitoring-and-management-console.desktop
-> Found java-policy-settings.desktop
-> Found java-visualvm.desktop
-> Found javaws-launcher
-> Found jdk.csh
-> Found jdk.sh
==> Validating source files with md5sums...
jdk-7u9-linux-x64.tar.gz ... FAILED
derby-network-server ... Passed
derby-network-server.conf ... Passed
java-monitoring-and-management-console.desktop ... Passed
java-policy-settings.desktop ... Passed
java-visualvm.desktop ... Passed
javaws-launcher ... Passed
jdk.csh ... Passed
jdk.sh ... Passed
==> ERROR: One or more files did not pass the validity check!
The build failed.

Det commented on 2012-10-25 12:45

@galaux, merge? Erm, I wonder what would be the right way to take your message then because 1) the two _were_ merged, they _aren't_ that anymore and 2) I _have_ explained this so many times it might actually even start to piss me off this tiiiny slightest bit to see people invariably repeating the same question I already answered before it was even asked (damn well even). Seriously, I _just_ quoted to wonder and now you're telling me you have absolutely no idea I did, even though it was the 3rd message from the top. Not even behind the "Show all XX comments" button excuse.

Well, credit where it's due, I wouldn't have to do anything _myself_, since it seems like there's inevitably someone else already clarifying it for you guys. But I just can't understand how can somebody come up here and say "I see no reason why this was done" when the answer is _right there_.

=> The JDK provided JRE is the one meant for development, which is the whole _point_ of this package. <=

hgabreu commented on 2012-10-25 10:22

He did not merge them. JRE was always part of the JDK. He just changed the package info to avoid having everybody download a repeated unnecessary package.

galaux commented on 2012-10-25 08:41

Don't take it wrong but I see no reason nor explanation as to *why* you merged JRE *back* into JDK.

FernandoBasso commented on 2012-10-23 15:45

Thanks.

Det commented on 2012-10-23 14:00

Oh, I am just too nice. FernandoBasso, I included your alternative mirrors.

Det commented on 2012-10-23 12:39

I wonder if there's a reason there's always _some_ dev not really following through with the big updates I make here.

@wonder, this is not unknown. It's just buried in the comment history you saw not essential enough to go through. This is what it said anyway (which, by the way I posted at the _exact_ same time I uploaded -2 and have been clarifying ever since):

"Since jdk-devel seems to be working just fine, I'll proceed with this. As some of you already know, JDK already provides its own debug JRE, which historically I've just been replacing with the regular one and making it depend on it.

But this is no longer the case, my friends. From now on this package will be both providing and thus conflicting with jre. This way you no longer have to download both upon every new release.

We'll see how it goes."

@FernandoBasso, the only thing I could possibly do is to change the source to the http://uni-smr.ac.ru/ one. It would be your job to complain to Oracle for the condition of their independent servers when CLI tools are being used.

@kkl2401, that's not entirely how it went, as my quote tells. At the time I actually _replaced_ JDK's /opt/java/jre folder with that of JRE's. Libattach.so and libsaproc.so are the only two files added in JDK's JRE. Those were actually the only two files I had to pull to make the JDK stuff like 'jconsole' to work. The rest is just added debug symbols.

kkl2401 commented on 2012-10-23 10:22

So? jdk used to depend on jre. If you installed jdk, you had more or less the same files on your disk, only they were in two packages. I for one am glad that now I don't have to update two packages from AUR but only one.

wonder commented on 2012-10-23 10:14

for years we had jre and jdk. for some unknown reason, you decided to include jre in jdk.

FernandoBasso commented on 2012-10-22 23:53

100 92.8M 100 92.8M 0 0 77533 0 0:20:55 0:20:55 --:--:-- 49068
==> ERROR: Failure while downloading jdk-7u9-linux-i586.tar.gz
Aborting...
notice: jdk failed while building, remove source files (/home/nando/Aurget_Files/jdk)? [Y/n] Y
warning: package jdk failed to build and won't be installed.
:: Retrieving source tarball from AUR...

For some reason, I always get this error and have to manually download the package...

Det commented on 2012-10-20 16:18

To the last one: Yes.

This provides all the virtual packages that jre does ('java-runtime=7' 'java-runtime-headless=7' 'java-web-start=7') plus the distinct one of its own ('java-environment=7').

Every app that worked before will keep on doing so.

nostalgix commented on 2012-10-20 12:01

@Det Oh. And what about packages that depend on jre? Is there a way to fix those dependencies somehow? Or shouldn't I care about that because the packages will still work when I replaced jre with jdk?

Det commented on 2012-10-19 20:54

@nostalgix, because you were _supposed_ to do so. The whole idea of this bump was to get _rid_ of jre.

EgidioCaprino commented on 2012-10-19 19:21

I solved, sorry.

https://bbs.archlinux.org/viewtopic.php?pid=1178179#p1178179

nostalgix commented on 2012-10-19 19:14

I don't get it. I now removed jre to update jdk. But now I can install the new jre either, because still jdk and jre conflict.

EgidioCaprino commented on 2012-10-19 06:30

I cannot install it. I get this error: https://bbs.archlinux.org/viewtopic.php?id=150975

Det commented on 2012-10-18 21:22

No, JRE is for running, JDK for also debugging and developing. The packages upstream didn't change a thing.

The only difference in the JDK provided JRE is that it includes things like debug symbols (meant for development).

Jristz commented on 2012-10-18 20:52

outside all, jre are...for view web apps and jdk the debug and other progrs like javaws, but now jdk provide all neded for jre and jdk right?????

Jristz commented on 2012-10-18 20:50

pacman -Rdd jre, remove jre but not they dependency or depen-on this one

Det commented on 2012-10-18 16:34

Ahh, of course. Yeah, well that's the only way it can be done. Makepkg doesn't support drop-in replacing packages.

E: Or does it actually, I dunno :D. At least if you remove those files it works.

Det commented on 2012-10-18 16:30

Ahh, of course. Yeah, well that's the only way it can be done. Makepkg doesn't support drop-in replacing packages.

silent commented on 2012-10-18 16:23

Yes, yaourt asked me about the conflict and jre should have been removed completely. It is not nice to force removal as 33 packages depend on jre, but OK.

silent commented on 2012-10-18 16:22

Yes, yaourt asked me about the conflict and jre should have been removed completely. It is not nice to force removal as 33 packages depend on jre, but OK.

silent commented on 2012-10-18 16:19

Yes, yaourt asked me about the conflict and jre should have been removed completely. It is not nice to force removal as 33 packages depend on jre, but OK.

Det commented on 2012-10-18 16:18

Pfft.. but it doesn't make sense because first off, jre actually _conflicts_ with this one now (so you shouldn't be able to even get that far) and secondly, it's just a _symlink_, which should be removed before upgrading _anyway_ so in what point could it possibly convert itself into a folder?

I just tried installing jre and jdk 7.9-1 back and the -2 upgrade went just fine. I remember running into this problem at some point yesterday, though, but still no idea what's causing it.

nicoulaj commented on 2012-10-18 16:07

jre.

You have to force remove jre before upgrading jdk: sudo pacman -Rdd jre

Det commented on 2012-10-18 15:55

Uhh.. what package are those owned by (pacman -Qo)?

silent commented on 2012-10-18 15:52

error: failed to commit transaction (conflicting files)
jdk: /usr/share/licenses/jdk/COPYRIGHT exists in filesystem
jdk: /usr/share/licenses/jdk/LICENSE exists in filesystem
jdk: /usr/share/licenses/jdk/THIRDPARTYLICENSEREADME-JAVAFX.txt exists in filesystem
jdk: /usr/share/licenses/jdk/THIRDPARTYLICENSEREADME.txt exists in filesystem

Det commented on 2012-10-18 14:13

And to inform you guys too, I've now included PKGEXT=".pkg.tar" in this package because even on my 6-core system the compression still took almost two minutes. The downside of it is that the size also increased from 69 megabytes to 222, though. So happy HDD shoppings and naggings to make me change it back.

Det commented on 2012-10-18 13:55

Since jdk-devel seems to be working just fine, I'll proceed with this. As some of you already know, JDK already provides its own debug JRE, which historically I've just been replacing with the regular one and making it depend on it.

But this is no longer the case, my friends. From now on this package will be both providing and thus conflicting with jre. This way you no longer have to download both upon every new release.

We'll see how it goes.

giniu commented on 2012-10-16 19:39

Please add provides java-web-start where appropriate, see https://bugs.archlinux.org/task/31595 for reference - official openjdk (icedtea) packages now provide this (in svn). Thanks for maintaining this package btw!

akurei commented on 2012-08-30 20:27

Thank you for the quick response update! <3

Manouchehri commented on 2012-08-30 19:49

Updated PKGBUILD for 7u7:

http://sprunge.us/AbSA

iiiypuk commented on 2012-08-23 10:09

Thank you!

Det commented on 2012-08-23 09:58

Yeah it does. Use the cookie flag.

iiiypuk commented on 2012-08-23 09:48

The link does not work.
http://download.oracle.com/otn-pub/java/jdk/7u6-b24/jdk-7u6-linux-i586.tar.gz

Det commented on 2012-08-23 09:07

To comment?

iiiypuk commented on 2012-08-23 09:06

Unauthorized Request

dront78 commented on 2012-07-26 05:34

there is a conflict installing jre after jre6 the same time in
/usr/lib/mozilla/plugins/libnpjp2.so

Det commented on 2012-07-25 07:51

The name of the tarball didn't change. The size did. It would've been enough to just remove the old one.

Don't even understand how would you possibly _have_ to regenerate the md5sums that are already there.

FernandoBasso commented on 2012-07-24 13:05

I had to manually download the .gz file with:
curl -vfLC - --retry 3 --retry-delay 3 -O --header "Cookie: gpw_e24=h" http://download.oracle.com/otn-pub/java/jdk/7u5-b05/jdk-7u5-linux-i586.tar.gz

I also had to generate md5sum for the .gz file and place the md5sum key in the first line of md5sums array
in the pkgbuild.

Malix commented on 2012-07-14 19:19

noneio: Dependencies jre libx11

install jre from aur first.

Anonymous comment on 2012-07-14 19:16

» noneio╺─╸[java]; makepkg -s
==> Making package: jdk 7.5-1 (Sat Jul 14 13:57:05 EDT 2012)
==> Checking runtime dependencies...
==> Installing missing dependencies...
error: target not found: jre

Det commented on 2012-06-23 21:19

No, I mean tame, as in "unwild".

Osleg commented on 2012-06-23 21:18

Still correct.
Anyway, thank you for your assist, have JDK and can install jython now :) Tnx :)

Det commented on 2012-06-23 21:17

Tame guesses are worthless.

Osleg commented on 2012-06-23 21:14

[...]
* Connected to download.oracle.com (58.27.22.9) port 80 (#1)
[...]
> Host: download.oracle.com
[...]

I guess my wild guess was correct :)

Det commented on 2012-06-23 21:00

Feels so dumb when you don't even think of that. So out of curiosity, what's the ip of it when you do:

curl -vfLC - --retry 3 --retry-delay 3 -O --header "Cookie: gpw_e24=h" http://download.oracle.com/otn-pub/java/jdk/7u5-b05/jdk-7u5-linux-i586.tar.gz

For me it says:
[...]
* Connected to (nil) (213.248.111.17) port 80 (#0)
[...]
> Host: download.oracle.com
[...]

Osleg commented on 2012-06-23 20:49

a wild guess - oracle redirect me to a server which closer to my current location and it down currently.
Other wild guess - my ISP blocking <b>only</b> 64bit pkg of jdk... But i think first one is more likely to be true :)

Det commented on 2012-06-23 20:44

Oh, that's okay. I got time. But just letting you know that I still can download the 64-bit one just fine so I'm not quite sure what's going on up there in your end.

Osleg commented on 2012-06-23 20:41

Oh looks like we posted ~ at same time :) Thanks for the link, downloading it now :)

Osleg commented on 2012-06-23 20:39

I'm sorry i bothered you, looks like oracle have issues with x86_64 package. Was trying to download i586 and it worked just fine but 64bit package gives me connection reset.
I guess i just have to wait till they fix it. >_<

Det commented on 2012-06-23 20:36

That's interesting. You can download the file with your browser, right?: http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1637583.html

Accept the license, download the tarball, place it in $startdir (the folder containing the PKGBUILD) and build. You don't have to touch the PKGBUILD.

If you can't download it even then (eg. even access the site), then there's something wrong between you and Oracle. In that case just get it from here: http://uni-smr.ac.ru/archive/dev/java/SDKs/sun/j2se/7/

Det commented on 2012-06-23 20:34

That's interesting. You can download the file with your browser, right?: http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1637583.html

Accept the license, download the tarball, place it in $startdir (the folder containing the PKGBUILD) and build. You don't have to touch the PKGBUILD.

If you can't touch it even then (eg. even access the site), then there's something wrong between you and Oracle. In that case just get it from here: http://uni-smr.ac.ru/archive/dev/java/SDKs/sun/j2se/7/

Osleg commented on 2012-06-23 20:14

Downloading with curl works fine both for ftp and http but not for jdk, could you possible assist me of how to modify PKGBUILD to feed him the file manualy?

Det commented on 2012-06-23 20:03

Works fine here. You scared the sh*t outta me.

I did some Googling and that might be caused by some problem in your network infrastructure too (firewall, etc.).

You should try downloading some other files from FTP/HTTP servers (with curl) to pinpoint what's wrong. Oracle servers work fine (at least they do now).

Osleg commented on 2012-06-23 17:19

Cannot install JDK, curl failing with:
-> Downloading jdk-7u5-linux-x64.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:13 --:--:-- 0
curl: (52) Empty reply from server

Det commented on 2012-05-07 10:01

Just getting you guys caught up too that we can now download the jre tarballs straight from the Oracle site by defining the cookie through DLAGENT.

And yes, credit goes to EasySly.

Det commented on 2012-05-04 11:54

So I guess this is a 'left' issue for my part, eh?:

┌┌(det@Archlinux)┌(424/pts/0)┌(01:12pm:05/04/12)┌-
└┌(%:~)┌- ls -l /usr/share/applications/java-monitoring-and-management-console.desktop
-rw-r--r-- 1 root root 168 May 4 10:31 /usr/share/applications/java-monitoring-and-management-console.desktop

I don't know what's wrong with your system (or the build for that matter) because I still can't reproduce that here, but updated anyway.

Also you don't need to use the word 'please', as long as it's something sane you're asking.

seblu commented on 2012-05-04 09:58

Right issues:

$ ll /usr/share/applications/java-monitoring-and-management-console.desktop
-rw------- 1 root root 168 2012-05-03 16:15 /usr/share/applications/java-monitoring-and-management-console.desktop

please use install with right in your PKGBUILD instead of cp

Det commented on 2012-05-02 12:56

The http://uni-smr.ac.ru guys have caught up.

sjakub commented on 2012-04-30 20:13

I just tried both jre and jdk on a machine that was not updated yet. There were no problems, and the process is actually really nice.
The loop was indeed a great idea and it works awesome. Thank you and keep up the good work! :)

(As a side note, I can't believe how arrogant company Oracle is :/ )

Det commented on 2012-04-29 17:17

Yeah, that makes a lot more sense. I added a $SRCDEST support, but since $XDG_DOWNLOAD_DIR is seemingly only set after running 'xdg-user-dirs-update' (and even then it points to $HOME/Downloads by default), I'm not gonna bother with it unless somebody starts complaining. The PKGBUILD is already fat as shit.

xduugu commented on 2012-04-29 14:31

> Not really following you there.
>
> 1) $SRCDEST is for makepkg-downloaded sources, right? Does anybody actually download their other stuff in there?

I prefer to store all the sources in one place and it's annoying to have to copy the source back to the location where I downloaded it the first time when I rebuild a package. Since the source is not in the source array, makepkg does not look for the source in SRCDEST anymore on its own.

> 2) It's simpler to have the source in the same directory for rebuilds. Why would you wanna symlink it e.g. from your desktop?

I usually remove the old package directory, but like to keep the source for the case of pkgrel increments. It doesn't matter if it is a symlink or a regular file in srcdir, but the source should be kept in its original location.

> 3) Also is that the same thing with $XDG_DOWNLOAD_DIR? Because I don't have any power over where the user's gonna download the source with his browser.

Afaik, that's the default download location for firefox and chrome/-ium.

Det commented on 2012-04-29 14:01

@sjakub, I did the file name thing you mentioned. The re-request thing _I_ mentioned proved to be easy as hell by using an until loop.

Bash is actually a pretty nice language for things like this.

Det commented on 2012-04-29 13:06

Well, libsaproc.so and libattach.so (located in /opt/java/jre/lib/$_arch, not /lib) are both jdk files so that's still quite interesting.

Anonymous comment on 2012-04-29 03:00

D'oh, I'm getting mixed up. The one I installed last night must have been jre, which goes through a very similar process (and the handling is the same since you maintain both). It was the one that was throwing the errors, which it said had to do with versioning conflicts. I think one of the ones it had me remove was libattach.so? I can't remember, as it was late and I didn't pay it much attention.

Det commented on 2012-04-29 02:20

Well, it's not .rpm, as I'm also already mentioning the tarball thing ("[...] download the tarball (.tar.gz) yourself").

The arch thing is sort of matter of opinion. It's pretty easy to just do `uname -m`, but of course even easier not to. I'll think it over. I'll probably also make the user-intervention part to re-ask for the tarball if it wasn't found, instead of just ending the build.

E: Also, sorry about getting a bit defensive there the last time. I figured you thought it was all my fault, when you mentioned the manual download. Actually, it seems like heftig was the only one who did.

E2: @palintropos, no, you don't have to apologize, if you have a genuine problem. But the thing is that I don't understand any of it. First of, this package doesn't install _anything_ to /lib and I can't think of a single case when an error would instruct you to remove something from there. About the second issue, you either downloaded a wrong package (e.g. jre, not jdk) or you really just don't have it there.

Det commented on 2012-04-29 02:18

Well, it's not .rpm, as I'm also already mentioning the tarball thing ("[...] download the tarball (.tar.gz) yourself").

The arch thing is sort of matter of opinion. It's pretty easy to just do `uname -m`, but of course even easier not to. I'll think it over. I'll probably also make the user-intervention part to re-ask for the tarball if it wasn't found, instead of just ending the build.

E: Also, sorry about getting a bit defensive there the last time. I figured you thought it was all my fault, when you mentioned the manual download. Actually, it seems like heftig was the only one who did.

E2: palintropos, no, you don't have to apologize, if you have a genuine problem. But the thing is that I don't understand any of it. First of, this package doesn't install _anything_ to /lib and I can't think of a single case when an error would instruct you to remove something from there. About the second issue, you either downloaded a wrong package (e.g. jre, not jdk) or you really just don't have it there.

Det commented on 2012-04-29 02:10

Well, it's not .rpm, as I'm also already mentioning the tarball thing ("[...] download the tarball (.tar.gz) yourself").

The arch thing is sort of matter of opinion. It's pretty easy to just do `uname -m`, but of course even easier not to. I'll think it over. I'll probably also make the user-intervention part to re-ask for the tarball if it wasn't found, instead of just ending the build.

E: Also, sorry about getting a bit defensive there the last time. I figured you thought it was all my fault, when you mentioned the manual download. Actually, it seems like heftig was the only one who did.

Anonymous comment on 2012-04-29 02:03

I'm sorry to have to come back with a problem, and have no intention of rescinding my compliment, but some things do appear to be wrong. For instance, I had to manually delete two .so files from /lib. That wasn't difficult and it told me which two (an error, not the install script), but couldn't the installer do that? Furthermore, once I removed those and followed the instructions, it seemed to update fine. However, when I did a full update again, jdk came up as needing to be upgraded, and it no longer finds the file even if I place it in the correct directory in /tmp.

sjakub commented on 2012-04-28 23:03

Yes, I do realize the license requirement. And that's not your fault, just Oracle's stupidity :/

The file name - it's possible to figure that out, but since the script knows the name it's looking
for why doesn't it just display it? It could be rpm, and if you're dealing with several
machines with different archs you have to stop and think which one it is. All of that
could be avoided by adding that name to the message.

Det commented on 2012-04-28 10:19

Ok. Thanks. First compliment I guess.

Anonymous comment on 2012-04-28 03:33

I actually just wanted to stop by and comment on how well I thought it handled that transition. That was a stupid move on Oracle's part, EULAs suck, and yet that was handled rather gracefully (and quickly!). Well done :-)

Det commented on 2012-04-27 23:46

My friend. It's more ridiculous to go run off with your mouth about a change without understanding why was it done in the first place.

heftig commented on 2012-04-27 23:16

This is ridiculous. Please revert to having the package download the JDK itself.

You're only providing a script to package the JDK. You're not redistributing it.

Det commented on 2012-04-27 22:36

Not really following you there.

1) $SRCDEST is for makepkg-downloaded sources, right? Does anybody actually download their other stuff in there?
2) It's simpler to have the source in the same directory for rebuilds. Why would you wanna symlink it e.g. from your desktop?
3) Also is that the same thing with $XDG_DOWNLOAD_DIR? Because I don't have any power over where the user's gonna download the source with his browser.

xduugu commented on 2012-04-27 22:14

Imo, you should also look in $SRCDEST for the source and smylinking the source should be enough instead of moving it. You could also rely on $XDG_DOWNLOAD_DIR instead of several hardcoded paths.

Det commented on 2012-04-27 16:57

You realize the license needs to be accepted first, right?

Also, I think the file name thing is pretty clear. It's not windows or solaris and it's not .rpm.

E: Also, the permission thing was fixed long before seblu mentioned it. I just don't bump the pkgrel, if that's all there is.

Det commented on 2012-04-27 16:57

You realize the license needs to be accepted first, right?

Also, I think the file name thing is pretty clear. It's not windows or solaris and it's not .rpm.

E: Also, the permission thing was fixed a long time before seblu mentioned it. I just don't bump the pkgrel, if that's all there is.

Det commented on 2012-04-27 16:56

You realize the license needs to be accepted first, right?

Also, I think the file name thing is pretty clear. It's not windows or solaris and it's not .rpm.

E: Also, the permission thing was fixed a long time before seblu mentioned it. I just don't rebuild my packages, if that's all there is.

Det commented on 2012-04-27 16:45

You realize the license needs to be accepted first, right?

Also, I think the file name thing is pretty clear. It's not windows or solaris and it's not .rpm.

Det commented on 2012-04-27 16:36

You realize the license needs to be accepted first, right?

Also, I think the file name thing is pretty clear. It's not linux or solaris and it's not .rpm.

sjakub commented on 2012-04-27 16:31

Det: Things like that (permissions) should be done by the PKGBUILD.

Also, it looks like now it is required to download the package manually.
It would be helpful if it actually said what is the file name you're expected to download.

Det commented on 2012-03-09 09:30

So make them?

seblu commented on 2012-03-09 09:26

/usr/share/applications/java-monitoring-and-management-console.desktop and /usr/share/applications/java-visualvm.desktop are not world redable.

Det commented on 2012-03-08 10:16

Just updated jre. No worries.

kingguru commented on 2012-03-08 09:23

Hi again,

I solved my problem by removing the "rhino" package. According to pacman it was installed as a dependency on another package, but that package was no longer installed so I could safely remove it.

Wasn't that obvious, so someone else might find that information useful.

kingguru commented on 2012-03-08 09:13

Hi there,

When attempting to do an update on my machine that has this package installed (unfortunately I cannot use openjdk), pacman wants to install jre7-openjdk-headless.

As far as I understand, the "java-runtime-headless" package is the java runtime without some GUI libs etc., which means that the full JRE should provide headless as well.

Should this package be update to provide "java-runtime-headless"?

Det commented on 2012-01-12 09:50

Actually I already told this in the jre comment section a while back. Just gotta click *Show all 24 comments*: https://aur.archlinux.org/packages.php?ID=51908&comments=all

But glad I got to see karol's response too.

karol_007 commented on 2012-01-12 03:48

@wallacecomputer
It's in the pacman's man page and 'pacman -Rh' has it too.
The man page doesn't have a literal '-dd' anywhere but it says "Specify this option twice to skip all dependency checks." pacman devs want to keep it that way (a bit hidden) because they say people overuse this option and break their systems (and whine about it to the devs).

Anonymous comment on 2012-01-12 02:55

Just a quick NOTE/Tip for anyone trying to replace openjdk and having problems. Run ( sudo pacman -Rdd jre7-openjdk ) to remove it! Had to search for 20 minutes to figure that one out..............lol

Peace.............Arch

Det commented on 2012-01-07 16:16

Mistake from my previous cosmetic update. Fixed now.

Anonymous comment on 2012-01-07 15:39

VisualVM doesn't work:

java.lang.UnsatisfiedLinkError: no attach in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)

libattach.so is missing. WTF?!

# tar xfv /tmp/jdk-7-linux-x64.tar.gz jdk1.7.0/jre/lib/amd64/libattach.so
jdk1.7.0/jre/lib/amd64/libattach.so
# [root@server lib]# cp jdk1.7.0/jre/lib/amd64/libattach.so /opt/java/jre/lib/amd64/

(via https://bbs.archlinux.org/viewtopic.php?pid=1037562#p1037562)

nicoulaj commented on 2012-01-05 19:10

For those interested, I have created a rc.d daemon package for jstatd (https://aur.archlinux.org/packages.php?ID=55288).

Det commented on 2011-12-21 16:12

I included the missing two libs from the 'jre' folder in this package. Rebuild if you need them (won't force anybody else to).

Anonymous comment on 2011-12-21 13:30

Does not work jconsole (java-monitoring-and-management-console.desktop) - no connect - error

Use the JRE from the jdk-7u2-linux-x64.tar.gz.
For JDK not used JRE from the jre-7u2-linux-x64.tar.gz.

Det commented on 2011-11-28 15:45

Ok. Done here too.

Det commented on 2011-11-27 21:25

"Updated". I'll clean up the PKGBUILD tomorrow (still uses lynx, etc).

Det commented on 2011-11-27 21:25

"Updated". I'll clean up the PKGBUILD tomorrow (still uses lynx, and so on).

Atsutane commented on 2011-11-27 20:42

JDK/JRE are no VCS packages, so it's a fix version they download, makepkg output as "evidence" is completely useless. Please update the package properly and check the upstream site for updates.

Det commented on 2011-11-27 18:45

Ehm... and you can't just check the upstream's home page for the latest version of JDK?

Have a look: http://www.oracle.com/technetwork/java/javase/downloads/index.html. What does it say?:

"Java SE 7u1
This release includes many security fixes.
Learn more"

Oh my gosh! I was wrong after all!

dserban commented on 2011-11-27 18:41

Build log = makepkg output.
Please provide the output of makepkg.
It will show whether the file being downloaded from upstream during the build process is version 7u1 or another version.

Det commented on 2011-11-27 18:28

Right...

1) I have only flagged this package once, jre twice.

2) What the _hell_ do you mean with a "build log". JDK "7u1" has been released over a month ago - this one says it's "7", Q.E.D.: it's out-of-date.

Why is it so hard to understand?

dserban commented on 2011-11-27 17:56

Simply claiming "Nope, it doesn't" is not enough, you need to provide some hard evidence, e.g. a build log.
Please provide a build log.
Also, please do not abuse the "flag out-of-date" button.
Unflagging.

Det commented on 2011-11-27 14:19

Nope, it doesn't.

dserban commented on 2011-11-27 13:59

The PKGBUILD builds the latest version of upstream, correctly.
Unflagging.

Det commented on 2011-11-07 13:46

This too should probably have a pkgver of "7u1" instead of "7".

rtimush commented on 2011-09-06 10:53

Agree with Boris-B, src.zip is an important part of the JDK.

Boris-B commented on 2011-09-01 15:56

In the PKGBUILD the src.zip file is removed form the root of the jdk install directory. This file is used by IDEs like eclipse to determine the name of certain thing such as function arguments. I think it would be preferable to leave it in the install.

dserban commented on 2011-08-28 14:26

@cuihao, it's because Oracle - in their infinitewisdom - changed the licensing terms and JDK is no longer freely redistributable.
https://mailman.archlinux.org/pipermail/arch-general/2011-August/021671.html

cuihao commented on 2011-08-28 14:21

Why removed from community repo?

dserban commented on 2011-08-28 13:26

Done.

Syco commented on 2011-08-28 11:50

md5sum's array is wrong, please add '45c15a6b4767288f2f745598455ea2bf' at the end.

msquared commented on 2011-08-27 20:19

Already in community repository. Please request deletion.