I have been offered the update this morning from 1.6.32I use LMDE64 (tracking testing) and tracks this repo: deb http://www.duinsoft.nl/pkg debs allThe update is triggered by the package: update-sun-jre. I find its use very convenient. All java links (Firefox 12, LibreOfice...) are updated too. Web site and install info here: http://www.duinsoft.nl/packages.php?t=en

I have been offered the update this morning from 1.6.32I use LMDE64 (tracking testing) and tracks this repo: deb http://www.duinsoft.nl/pkg debs allThe update is triggered by the package: update-sun-jre. I find its use very convenient. All java links (Firefox 12, LibreOfice...) are updated too. Web site and install info here: http://www.duinsoft.nl/packages.php?t=en

By the way, a warning to everyone who uses the duinsoft script. Be prepared for an unexpected failure if Oracle ever fixes the text on the download page at java.com. They claim the file is self-extracting - it isn't.Unfortunately, the script uses a sed scan on that page for the text "Linux (self-extracting" to find the url for the 32 bit package. If they ever change that part of the page, the script will fail (until it is fixed, of course).

GeneC wrote:I now have two Java's in Chrome 'plugins'Do I disable the old one?Or are they separate things.

The duinsoft script pulled in a different version and that was installed in /opt/java. If you used the method mentioned in the first posting in this thread to install 1.0.6_31, you should have another (slightly older) installation in /usr/lib/jvm. As that was installed from a deb, you should be able to remove it using dpkg.

Last edited by grizzler on Wed May 09, 2012 1:10 pm, edited 1 time in total.

By the way, a warning to everyone who uses the duinsoft script. Be prepared for an unexpected failure if Oracle ever fixes the text on the download page at java.com. They claim the file is self-extracting - it isn't.Unfortunately, the script uses a sed scan on that page for the text "Linux (self-extracting" to find the url for the 32 bit package. If they ever change that part of the page, the script will fail (until it is fixed, of course).

meh figured what the hell. I don't use 99.99% of the repos on my list I just add them and try to keep them more or less updated. Actually trying to find someone that will mirror the list and maintain it, as I received bad news at doctor last week. Not sure how much longer I will be able to keep the list maintained.

My actual working sources.list is pretty basic. sid, exp, dmm, Google repos for Chrome and Google's Music manager, and Jitsi.

I have been offered the update this morning from 1.6.32I use LMDE64 (tracking testing) and tracks this repo: deb http://www.duinsoft.nl/pkg debs allThe update is triggered by the package: update-sun-jre. I find its use very convenient. All java links (Firefox 12, LibreOfice...) are updated too. Web site and install info here: http://www.duinsoft.nl/packages.php?t=en

The downloaded package is a tarball (gzip compressed tar file) with a small unpack script tacked to the front (head -n 26 update-sun-jre.bin to see what that small script looks like). The tarball contains two files: the script itself and another tarball with support files (update-sun-jre-support.tar.gz). You should not unpack that support tarball, but leave it in the same directory as the script.

The file update-sun-jre.bin is a tarball preceded by a small script (the one Craig showed in the posting above). If you run it with the -x switch, it will stop after unpacking the tarball part as the main script (update-sun-jre) and the support tarball (update-sun-jre-support.tar.gz). These will appear in the current directory. If you want to examine the support files, simply use tar or nautilus to unpack the support tarball in the current directory (it will create a 'usr' subdirectory with some more subdirectories and files) or look at the tarball with an archive manager like file-roller.

If you run the main script it will unpack the support tarball (ignoring anything you may have unpacked manually), placing the support files in the right place in the filing system structure. Running the script with the 'remove' command, should also remove the support files (but not anything you may have unpacked manually).