JDK Timezone Update Tool

A

AB-stromer

Well-Known Member
Hallo,
hätte vielleicht jemand eine Datei tzupdater-1_3_29-2010f.zip (JDK US DST Timezone Update Tool - 1_3_29) für mich?
Bin wohl zu blöd, das auf den Sun/Oracle Seiten zu finden, ich komme immer wieder nur darauf, das aktuellste 1.3.31 downloaden zu können, oder ansonsten doch bittschön einen Sales Representative ansprechen zu mögen. Ältere Versionen zu finden gelingt mir nicht...

VG
 
Braucht man eigentlich das "US DST Timezone Update Tool" in Europa? Habe mir das bisher immer auf der SUN/Oracle-Seite runtergeladen, bin mir aber garnicht sicher, ob ich das wirklich brauche.
 
oder ganz ohne ... tzupdater*. Normalerweise wird das kaum je benötigt.
Code: 
entweder
$ make  WITHOUT_TZUPDATE=yes  usw.

oder in /var/db/ports/deinjavaport/options:

WITHOUT_TZUPDATE=true
Es gibt übrigens in diesem ganzen Oracle Seitenlabyrinth eine Seite mit 'historischen' Downloads. Url ist allerdings nicht ganz keicht zu finden und ich hab sie auch nicht mehr :( .
Da findest du auch den tzupdater.
 
Elwood schrieb:
Braucht man eigentlich das "US DST Timezone Update Tool" in Europa? Habe mir das bisher immer auf der SUN/Oracle-Seite runtergeladen, bin mir aber garnicht sicher, ob ich das wirklich brauche.
Zum Vergrößern anklicken....

Der Punkt ist, das ein make von openoffice unter 8.1-REL nach Standardprozedur ohne diese Datei mit Fehler abbricht, belanglos ob man sie braucht oder nicht...
 
metro schrieb:
oder ganz ohne ... tzupdater*. Normalerweise wird das kaum je benötigt.
Code: 
entweder
$ make  WITHOUT_TZUPDATE=yes  usw.

oder in /var/db/ports/deinjavaport/options:

WITHOUT_TZUPDATE=true
Es gibt übrigens in diesem ganzen Oracle Seitenlabyrinth eine Seite mit 'historischen' Downloads. Url ist allerdings nicht ganz keicht zu finden und ich hab sie auch nicht mehr :( .
Da findest du auch den tzupdater.
Zum Vergrößern anklicken....

Die Option für make hat bei mir nicht funktioniert, ich musste tatsächlich die Datei beschaffen.

"Seitenlabyrinth" ist das richtige Wort! :)

Ich frage mich, wie lange die Abhängigkeit zu diesem Kommerzgiganten Oracle da noch tragfähig ist...
 
Ich habe am Do das JDK16 (Brauch ich für Liferay) sowie OpenOffice installiert. Sollte also noch alles haben. Melde dich mal und schick dir das dann per Mail.
 
Wenn man den Link anklickt, der vom JDK-Port ausgespuckt wird, dann ist man doch direkt auf der Webseite, wo man das Teil herunterladen kann. Wo ist das Problem?
 
Um das JDK zu bauen habe ich zwei verschiedene Versionen vom TZ Updatetool gebraucht. Also auf der Seite habe ich nur die neueste Version gefunden. Aber nicht die ältere.
 
@nakal
Das Problem ist, daß einige, wenn nicht alle java-jd* ports auf distfiles von Sun/Oracle verweisen die es da nicht mehr auf den jetzt aktuellen Seiten gibt.
Sun/Oracle stellt auf die gelinkten Seiten (nach Login und tralala ) nur die jeweils aktuellen Versionen.
Diese widerum sind nicht das, was die Ports wollen.
Wie gesagt, irgendwo gibt es einen Link zu 'historischen' Downloads mir einer Suchfunktion.

@AB-stromer
make clean vor Optionswechsel ?
 
Fusselbär schrieb:
Schau mal: http://forums.freebsd.org/showthread.php?t=17409
Ich würde unoffizielle Download Quellen aber nur benutzen, wenn es gar nicht anders ginge und wenn ich die genauen Hashsummen (distinfo) für die korrekte Datei hätte.
Zum Vergrößern anklicken....

Dank der Prüfsumme in distinfo ist es ziemlich wumpe, woher man die distfiles nimmt. Wenns nicht passt, wird man schon darauf hingewiesen und die Installation wird abgebrochen.
Gerade für den TZUpdater bietet sich das an, weil Sun/Oracle da alle paar Tage eine neue Version rausbringt und die davorgehenden irgendwo versteckt.
Eigentlich sollte man eine Belohnung dafür bekommen, wenn man sie dann doch noch findet.
 
das ist mein Ansatz:
wenn es denn mal damit nicht geht und ich kein aktuelles File bekommen kann oder ein zu aktuelles, dann ändere ich einfach die Information in distinfo so, dass es zu meinem file passt und sehe, was passiert.
Gerade beim TZ...updater erwarte ich da keine Schwierigkeiten.

openjdk fragte wohl gar nicht erst danach und ich meine, dass ich das auch schon mal erfolgreich benutzt habe.
 
Aber gerade deswegen gibt es ja die Checksummen. Wenn du dir was aus dem Netz ziehst, und die Checksumme stimmt nicht, sollten bei dir eigentlich die Alarmglocken angehen. Entweder die Datei ist korrupt oder sie entspricht nicht dem, was der Port Maintainer abgesegnet hat (ja, es wird erwartet, dass ein Maintainer versteht, was ein Port macht und dass der Port nichts "böses" tut).
 
ich denke, du beziehst dich damit auf meinen Post.

Natürlich hast du mit deiner Bemerkung recht.
Tatsächlich habe ich aber schon häufiger erlebt, dass die Informationen aus der distinfo nicht immer funktionierten. Dabei erinnere ich mich an die win32-codes, die eine ganze Weile nicht zu dem passten, was genau von der HP des angegebenen Servers gezogen werden sollte. Diese Server, also die Quellen für die Pakete stehen ja auch irgendwo gelistet.
Gerade bei Java, also, wenn ich grundsätzlich eh auf Quellen von SUN angewiesen bin und die dort auch noch mit Checksumme hinterlegt sind, ist es doch egal, ob diese von mir manuell geprüft und die distinfo entsprechend angepasst wird, oder ob dies das Installationsscript automatisch erledigt. Da hätte ich keine Bedenken, also Sicherheitsbedenken. Funktion ist wieder eine andere Sache, weil die Versionen ja so nicht passen.
Das ist aber meist nicht unbedingt nötig, tatsächlich auch die auf Komma genaue Version zu haben. Meist funktionieren auch "verbotene" Kombinationen.
Vor einigen Tagen ist mir aufgefallen, dass mir eine Anwendung auf meinem Netbook fehlt, die ich mit kdeutils bekommen würde. Auf dem Netbook habe ich keine Ports und ziemlich alle Anwendungen mit pkg_upgrade installiert. kdeutils3 gab es gar nicht als Paket auf i386/packages-stable. Also nahm ich ein älteres Paket, das im Grunde nicht recht zu meiner installierten Version von KDE3 passen wollte und installierte halt dieses. Nach Zufügen einiger Links um die nun installierten Programme auch ihre libs finden zu lassen, funktioniert das ausgezeichnet. Natürlich ist sowas unsauber und sicher nicht generell zu empfehlen, aber bevor ich ganz auf eine liebgewonnene Anwenung verzichte, versuche ich mir halt zu helfen und weil meine Mittel da recht bescheiden sind, "murkse" ich dann halt rum.
Wenn dieser Murks dann auch noch funktioniert, geht es anderen vielleicht ähnlich und sie freuen sich dann vielleicht über entsprechende Anregungen oder Erfahrungsberichte.

Aber, wie gesagt, natürlich hast du recht: das FreeBSD Ports-System ist so ausgelegt, dass es funktioniert und wenn nicht, sollte eben nicht herumgemurkst, sondern die entsprechenden Maintainer informiert werden.
 
Ich kann dich ja schon verstehen und habe das selbst auch schon gemacht, nur sollte man dabei immer die nötige Vorsicht walten lassen. :)
 
Habe gerade wieder eine FreeBSD-Kiste mit Java ausgerüstet, diesmal mit dem diablo-jdk16.

Beim "make config" kann man das "tzupdate" einfach weghaken und gut. Damit löst sich dieses richtig ärgerliche tzupdate-Problem in Luft auf...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben