Re: Firefox 38.2.1 for eCS (OS/2) Beta 6 release

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Michaelhz
Beiträge: 23
Registriert: Mo 6. Jan 2014, 16:09

Beitrag von Michaelhz »

... nutzt doch einfach YUM+RPM. Die Diskussion um die falschen, bzw. veralteten DLL's nervt. Wenn die XUL.dll nicht geladen wird, sind die abhängigen dll's nicht installiert bzw. in der falschen Version vorhanden. Die Vielzahl der Bibliotheken läßt sich eben nur noch sinnvoll mit einem entsprechenden Datenbanktool verwalten.
Die Entwickler haben sich für YUM+RPM entschieden.
Die Entwicklungsgeschichte der aktuellen Firefox Version ist durchaus beeindruckend (Mitzulesen vor allem unter https://github.com/bitwiseworks/mozilla-os2/pulse und http://trac.netlabs.org/ports/timeline). Ausgehend von einer aktuellen fontconfig-Portierung sind viele neue und aktualisierte Bibliotheken implementiert worden. Der Nutzen geht m.E. weit über den aktuellen FF hinaus.

Von daher: Mein Dank und meine Anerkennung an die Programmieren und deren Ausdauer. So ein Projekt läßt sich nicht mit der richtigen Portion Leidenschaft umsetzen.

Michael
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Edit: nein geht doch nicht. XUL Fehler kommt nicht mehr, aber ein Trap.
Benutzeravatar
thorolf
Beiträge: 563
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Frank Wochatz » Mo 22. Feb 2016, 20:17 hat geschrieben:Kein Ahnung, bin eigentlich davon ausgegangen, das die Tree-Ansicht auch folgende DLLs im Baum anzeigt (macht sie ja auch, aber nicht alle, oder wie?). Ich hab nun alle FF-DLLs und die neuen Sachen gecheckt, aber nichts gefunden.

Btw das Firefox WPI enthält überhaupt keine DLLs der Pakete. Das ist exakt der gleiche Inhalt wie das ZIP, mit einem Installationscript und Icon. D.h. wer jetzt denkt, damit geht irgendwas einfacher - ja das spart das UNZIP. Das wars.
ich sage mal so, ich bin auch einem T42 mit eCS 2.0 und bislang nur FF 4.0 und 9.0 nun den "RPM-Weg" gegangen, war so schlimm nicht und hat am Ende funktioniert.

Ich habe zuerst den "Arca Noae Package Manager" und das Sprachpaket heruntergeladen:
https://www.arcanoae.com/resources/downloads/

WarpIN 1.0.19 muss installiert sein (ftp://ftp.netlabs.org/pub/warpin/warpin-1-0-19.exe), zudem die kLIBC Pathrewriters 1.0.2 oder neuer (https://repos.arcanoae.com/anpm/klibccfg_1_0_2_2.exe), letztere hatte ich nochmal heruntergeladen und drüber installiert und einmal gebootet.

Danach habe ich den ANPM installiert, dabei gleich das deutsche Sprachpaket mit ausgewählt, irgendwann hat er gefragt ob er YUM installieren soll, klar, sollte er, hat 50 MB heruntergeladen, installiert und ich habe nochmal neu gebootet. Dann wieder den ANPM aufgerufen, er wollte noch ein paar Pfade in den LIBPATH eintragen, ich meine zwar das hätte er schon, egal, machen lassen, nochmal gebootet - fast so "schön" wie bei Windows :-(

Wieder den ANPM aufgerufen und er wollte nochmal den LIBPATH ändern, ich habe es geprüft, war schon in der config.sys drin, also übersprungen.

Nun habe ich den ANPM einmal alle Pakete aktualisiert und noch folgende Repositories eingetragen, jedoch nur die "Stable" aktiviert:
arcanoae-rel Acra Noae Stable https://repos.arcanoae.com/release/$releasever/
arcanoae-sub Acra Noae Subscription https://repos.arcanoae.com/subscription/$releasever/
netlabs-rel Netlabs Stable http://rpm.netlabs.org/release/$releasever/$basearch/

Dann erneut alle Paket aktualisiert, es wurde nichts neues gefunden und "sicherheitshalber" nochmal neu gestartet.

EDIT:
Lt. Andreas braucht man die "exp"-Repos gar nicht, ich habe sie daher gelöscht, die "rel"-Repos sollen wohl gespiegelt sein, braucht man auch nur einen (bei uns ist "netlabs" vorzuziehen) und das "sub"-Repo geht vermutlich nur mit Zugangsdaten für die Subscription bei Arca Noae, da weiß ich aber nicht wie die einzutragen sind!


Jetzt habe ich lt. README die fehlenden Pakete über die Kommandozeile mit YUM installiert (siehe: https://github.com/bitwiseworks/mozilla ... README.OS2):

Code: Alles auswählen

yum install libc libgcc1 libstdc++6 pango freetype fontconfig zlib libkai pthread mmap
In der Anleitung steht das zwar alles einzeln drin, kann man aber auch mit einem Befehl erschlagen.

Und endlich kommt der Firefox, hier habe ich das WPI bei Hobbes runtergeladen http://hobbes.nmsu.edu/h-search.php?key ... ton=Search und installiert, dann mit "-ProfileManager" gestartet und eine Kopie des Firefox 9.0-Profils geladen.

Die Erweiterungen hat er alle übernommen und/oder aktualisiert, selbst das Sprachpaket wurde automatisch hochgerüstet, in der Vergangenheit hat das definitiv nicht funktioniert. Mehr kann ich nicht sagen, er braucht lange zum Starten, läuft dann aber halbwegs normal, die paar Web-Seiten die ich getestet habe, gingen auch.
So den ganzen Nachmittag verplempert, was ein Frust, ich bin jetzt erstmal durch damit. Ev. mal an einem anderen Tag... cya
Bei mir waren es nur 2 Stunden, auch deshalb, weil ich das Firefox-RPM gesucht habe.

Insgesamt eine erfreuliche Entwicklung, allerdings ist die Installation für die meisten Anwender eine Zumutung, zumal man das u.U. bei jeder neuen Version nochmal machen muss, weil keine neuen Abhängigkeiten erkannt und ggf. aufgelöst werden.

So gesehen wäre der Firefox prädestiniert dafür, als RPM-Paket verteilt zu werden, alles andere macht in der jetzigen Form keinen Sinn.

Oder aber das WPI "aufbohren" und dort alle Abhängigkeiten auflösen, wenn aber zukünftig wirklich der RPM-Weg gegangen werden soll, wäre ein RPM-Pakte sinnvoller (kann so schwer ja nicht sein, wenn es ordentlich portiert ist, müssen im Spec-File ja nur die benötigten Pakte mit aufgeführt werden, den Rest macht dann ja YUM)!
Zuletzt geändert von thorolf am Di 23. Feb 2016, 01:35, insgesamt 2-mal geändert.
Grund: Repos angepasst
Grüße,

Thorolf
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Selbstverständlich ist der FF eine erfreuliche Entwicklung. Nur die Distribution nicht.
Da die ZIP Installation für die Tonne ist, würde ich die garnicht mehr anbieten. Das wäre zumindest konsequent. Dann nur noch RPM. Allerdings schraube ich mir nicht einen dritten Systemtree mit 90% Ballast unter den Desktop. Schaut Euch mal bitte an was und wie da abgelegt wird, ein Albtraum. An dem Tag, an dem das unter OS/2 nur noch so läuft formatiere ich meine Festplatte, dann isses vorbei und ich kann auch gleich Linux benutzen...
Benutzeravatar
thorolf
Beiträge: 563
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Frank Wochatz » Mo 22. Feb 2016, 23:20 hat geschrieben:Selbstverständlich ist der FF eine erfreuliche Entwicklung. Nur die Distribution nicht.
Da die ZIP Installation für die Tonne ist, würde ich die garnicht mehr anbieten. Das wäre zumindest konsequent.
ne, ne, bitte grundsätzlich auch ein ZIP anbieten, das kann man nämlich immer und ohne Aufwand auspacken.
Dann nur noch RPM. Allerdings schraube ich mir nicht einen dritten Systemtree mit 90% Ballast unter den Desktop. Schaut Euch mal bitte an was und wie da abgelegt wird, ein Albtraum. An dem Tag, an dem das unter OS/2 nur noch so läuft formatiere ich meine Festplatte, dann isses vorbei und ich kann auch gleich Linux benutzen...
Ich sage mal so, ich hätte nichts gegen ein Linux (oder besser BSD) als Basis und eine WPS oben drauf, aber das will ja niemand.

Auf der anderen Seite steckt in einem aktuellen OS/2 schon jede Menge Linux, weil wichtige Treiber und viele Anwendungen von Linux nach OS/2 portiert wurden. Und die brauchen dann eben, neben den ganzen passenden Libs auch einen "Unix-artigen" Unterbau mit passenden Verzeichnissen, Zusatzprogrammen usw. Und im Grunde stört das auch nicht wenn da ein paar MB mehr an "Daten", einzig die Pfade werden u.U. länger.

Da ich schon seit langem viel Linux-Ports benutze, habe ich das "ux-root" sowieso, was ich bei einem Rechner-Wechsel einfach rüberkopieren und die Pfade in die Config.sys eintrage.

Nun kommt also auch noch YUM und bestimmt weitere "Linux"-Treiber und Anwendungen, somit weitere "Linux"-Erweiterungen, irgendwann hat man fast alles aus Linux nachgebaut und man darf sich die Frage stellen, ob es umgekehrt, also gleich Linux/BSD als Basis zu nehmen, nicht der bessere Weg gewesen wäre.

Aber manche haben trotzdem ihren Spaß daran und andere ziehen es vor aus den eigenen Fehlern zu lernen, anstatt die von anderen zu "nutzen".
Grüße,

Thorolf
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Hallo Thorolf,
thorolf » Mo 22. Feb 2016, 23:04 hat geschrieben: Nun habe ich den ANPM einmal alle Pakete aktualisiert und noch folgende Repositories eingetragen, jedoch nur die "Stable" aktiviert:
arcanoae-rel Acra Noae Stable https://repos.arcanoae.com/release/$releasever/
arcanoae-exp Acra Noae Experimental https://repos.arcanoae.com/experimental/$releasever/
arcanoae-sub Acra Noae Subscription https://repos.arcanoae.com/subscription/$releasever/
netlabs-rel Netlabs Stable http://rpm.netlabs.org/release/$releasever/$basearch/
netlabs-exp Netlabs Experimental http://rpm.netlabs.org/experimental/$re ... $basearch/
davon ist wirklich nur netlabs-rel sinnvoll.

Die arcanoae*-Quellen sind Spiegelungen, die wahrscheinlich in anderen Ländern besser erreichbar sind.

Bitte die Pakete aus den *-exp-Quellen wieder entfernen. Das sind Testversionen für die Entwickler und meistens noch fehlerhaft. (Experimental bedeutet auch tatsächlich experimentell.)
thorolf » Mo 22. Feb 2016, 23:04 hat geschrieben: So gesehen wäre der Firefox prädestiniert dafür, als RPM-Paket verteilt zu werden, alles andere macht in der jetzigen Form keinen Sinn.
Ja, das ist anscheinend geplant: https://github.com/bitwiseworks/mozilla-os2/issues/142
Andreas Schnellbacher
Benutzeravatar
thorolf
Beiträge: 563
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Hallo Andreas,
aschn » Di 23. Feb 2016, 01:08 hat geschrieben: davon ist wirklich nur netlabs-rel sinnvoll.

Die arcanoae*-Quellen sind Spiegelungen, die wahrscheinlich in anderen Ländern besser erreichbar sind.
das wußte ich nicht, es gibt als "Spiegel" wohl auch noch die "Rosental"-Repos?
Bitte die Pakete aus den *-exp-Quellen wieder entfernen. Das sind Testversionen für die Entwickler und meistens noch fehlerhaft. (Experimental bedeutet auch tatsächlich experimentell.)
Nun ja, in der Beschreibung stand Alpha/Beta, ich hoffte hier eigentlich den Beta-Build vom Firefox zu bekommen.

War aber nichts, da gab es nun was mit "bash" und "openssh", würde mich ja interessieren, aber Du meinst das taugt nix?

Aber ich habe die "exp"-Repos eh deaktiviert!

Ich passe meinen Post oben noch an ...
Grüße,

Thorolf
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

thorolf » Di 23. Feb 2016, 01:30 hat geschrieben: es gibt als "Spiegel" wohl auch noch die "Rosental"-Repos?
Keine Ahnung, aber es würd mich nicht wundern, wenn die in arcanoae umbenannt wurden.
thorolf » Di 23. Feb 2016, 01:30 hat geschrieben: War aber nichts, da gab es nun was mit "bash" und "openssh", würde mich ja interessieren, aber Du meinst das taugt nix?
Konkret weiß ich das nicht. In der Vergangenheit gab es aber häufiger Probleme mit den experimentellen Paketen. Vielleicht schreibt ja Silvan noch was dazu.
thorolf » Di 23. Feb 2016, 01:30 hat geschrieben: Aber ich habe die "exp"-Repos eh deaktiviert!
Ach so, war nicht so klar.
Andreas Schnellbacher
Werner.S
Beiträge: 104
Registriert: Mo 23. Dez 2013, 11:29
Wohnort: Nürnberg

Beitrag von Werner.S »

Hab jetzt gestern Abend nach einer Orgie.dll FF38.2.1 zum laufen gebracht.
Läuft so weit gut und auch schneller als der Alte. (24.8)
Nur:!
Nach dem beenden von FF steht das ganze System.
Nichts geht mehr. Keine Meldungen, nix.
Nach neu booten hat die prefs.js 0 Byte Größe.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Nochmals Danke an Jörg und Andreas für das Zusenden der DLL Pakete. Ich habe alle DLLs installiert. Die XUL Fehlermeldung kommt nicht mehr, laut PMDLL ist alles ok, dafür bekomme ich einen Trap im FF. Was mir noch aufgefallen ist: die Dateigrößen der DLLs aus den ZIPs sind fast alle anders als aus den RPM Archiven. Ich habe aber beide Builds ausprobiert. Ich habe gestern Nacht auch ALLE DLLs meines Systems mit Suchtools und DIR-Listings nach Doubletten überprüft (war übrigens alles ok). Außerdem wird in der readme die fntcfg2.dll aufgeführt, die aber in den Paketen nirgends enhalten ist (aber auch die habe ich auf anderem Wege installiert). Schade. Ich warte jetzt erstmal auf die angkündgte GA und benutze weiterhin Seamonkey. Wenn das mal vernünftig funktioniert und die Doku einen korrekten Überblick über die benötigten DLLs enthält bin ich auch gerne erneut mit einer finanziellen Unterstützung dabei. Im Moment denke ich allerdings in anbetracht des Ressourcenmangels, wir werden hier dem Beta-Status nicht entkommen.

Danke nochmal fürs mitfiebern.
ajunra
Beiträge: 375
Registriert: Mo 23. Dez 2013, 06:40
Wohnort: Insel Rügen

Beitrag von ajunra »

Hallo ihr!
Hat von euch denn jemand eine Ahnung, ob es denn mal wieder irgendwann (ideal wäre natürlich dann auch zu wissen wann) eine Firefox-Version oberhalb des BETA-Stadiums geben wird/soll? Die letzte nicht-BETA-Version ist ja schon etwas :roll: her...
Schöne Grüße von Deutschlands größter Insel
ajunra
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Silvan hat mir vor ein paar Wochen per Mail mitgeteilt, dass dieser neue Browser jetzt in den GA Status gehoben werden soll. Eine ordentliche Dokumentation gehört für mich dazu.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Zum Glück hat Dave vor ein paar Tagen einen Seamonkey 2.35 kompiliert (entspricht Gecko 38.0). Ich habe eine entsprechend angepaßte deutsche Version bisher nur in virtuellen Umgebungen erprobt. Macht zwar einen besseren Eindruck, ist aber noch nicht benutzerfreundlich verpackt. Drucken funktioniert, allerdings nahezu Multimedia-untauglich wie bei allen letzten Builds.

Apropos Drucken:
Mit dem neuen Firefox gelang es mir zumindest bei installiertem IBM Null Treiber in eine PDF-Datei zu drucken. Die Aussage, nach welcher nicht gedruckt werden kann, ist also wieder gezielte Desinformation, um den Nutzern in Zukunft CUPS aufzwingen zu können.
Benutzeravatar
thorolf
Beiträge: 563
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

ak120 » Di 23. Feb 2016, 14:11 hat geschrieben:Apropos Drucken:
Mit dem neuen Firefox gelang es mir zumindest bei installiertem IBM Null Treiber in eine PDF-Datei zu drucken. Die Aussage, nach welcher nicht gedruckt werden kann, ist also wieder gezielte Desinformation, um den Nutzern in Zukunft CUPS aufzwingen zu können.
mal abgesehen davon, das PDF-Drucken gehen soll, was ganau hat das mit "CUPS aufzwingen" zu tun?

Wie soll man zukünftig denn bitte sonst mit OS/2 drucken, wenn nicht mit CUPS???
Grüße,

Thorolf
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Wie soll man zukünftig denn bitte sonst mit OS/2 drucken, wenn nicht mit CUPS?
Für die meisten Anwender stellt sich die Frage eher entgegengesetzt. Einen lokal (seriell oder parallel) angeschlossenen Drucker mit CUPS zu betreiben, ist für Produktionssysteme praktisch schwer umsetzbar. Für heterogene Netzwerkumgebungen hat CUPS sicherlich Vorteile. Aber ein Drucksystem, welches nicht mit dem Systemzeichensatz klarkommt, taugt nur zum Druck von Testseiten und vielleicht noch paar bunten Bildchen.

Postscript-Drucker und Geräte mit unterstützten Emulationen (Laserjet, Epson, Proprinter, ...) wird es auch in Zukunft geben und können mit bestehenden Treibern genutzt werden.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Drucken wird überbewertet. ;-) Ich hab seit 5 Jahren (gefühlt: 10 Jahre) nichts mehr zuhause ausgedruckt.

Was ist eigentlich so schlimm daran den Umweg über PDF zu machen? Gerade wo das Drucken heutiger Dokumente unter OS/2 sowieso ewig dauert, macht ein Umweg mehr doch auch nichts mehr aus.
Andreas Schnellbacher
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Neues aus dem Detektivbüro: Eine weitere folgenschwere Fehlinformation der Dokumentation aka readme.os2 des neuen FF ist, dass nur DLLs aus den entsprechenden Archiven benötigt werden, und diese im Libpath liegen müssen. Richtig ist, dass
a) auch andere Dateien zwingend erforderlich sind
b) die Subdirectory-Struktur im Unixroot eingehalten werden muss.

Im Zusammenhang mit dem Fakt, dass die ZIP- und RPM-Archive nicht den gleichen Inhalt bieten (andere Dateien), ist das natürlich ein KO-Kriterium für eine ZIP Installation.

Für einen erfolgreiche ZIP Installation müssten in erster Linie die ZIP-Files auf Stand der RPM-Archive gebracht werden. Wenn die dann vollständig installiert werden, dürfte es eigentlich keine Probleme geben.

Ob mein Trap etwas damit zu tun hat, oder ob das einfach ein Bug ist steht nochmal auf einem anderen Blatt. Der neue Seamonkey steigt hier übrigens auch mit einem Trap aus.

Euer Jim Rockford
Benutzeravatar
thorolf
Beiträge: 563
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Hallo Frank,

anbei mal ein Post aus dem Usenet von Dave Yeo:
Betreff: Re: FF38 req. DLLs
Datum: Tue, 23 Feb 2016 19:01:16 -0800
Von: Dave Yeo <dave.r.yeo@gmail.com>
Newsgruppen: comp.os.os2.apps

A.D. Fundum wrote:
>> maybe glib
>
> The documentation isn't complete. For example:
>
>> INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'
> The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
> isn't.
gthreads are part of glib2 and really should be in the same zip.

> FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
> Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.
The new freetype dll should work with the last few releases and co-exist
with the mzfntcfgft DLLs

>> SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
>> page
> Thanks, SM is more important than FF and I do prefer static linking,
> for one to avoid this "complicated" mess.
https://bitbucket.org/dryeo/dry-comm-es ... en.os2.zip

> At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
> to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
> cannot load STDCPP6.DLL.
Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.

> The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
> PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
> CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.
Most of those are mozilla DLLs and Mozilla can find them by itself.
pthr01, mmap, pixman10, cairo2, pango100 and kai0 should be on the libpath.

> Yesterday it looked like it worked with PM DLL, after copying
> STDCPP.DLL to "." too, but it never really worked. It may have been
> some PM DLL bug.
>
> FWIW, I've only installed know, documented packages. For example, I
> haven't verified if I should update GCC473,DLL, and so on.
You need gcc1.dll along with its various forwarders such as gcc473.dll,
not the original gcc473.dll. Turns out all the GCC dlls are
interchangeable and should have been GCC1.DLL to start with.

> I'm almost
> installing it as if I'm a new user, without an install whcih is
> guaranteed to be fully up-to-date. All installed DLLs are verified,
> only SM could cause a conflict but I haven't used that, nor games with
> an own Z.DLL version.

BTW, plugin-container.exe doesn't correctly work yet (it's used to run
Flash in its own process space). What you should point PMDLL at is
XUL.DLL which will show you all the needed DLLs and with SeaMonkey
running the only ones in red are the Mozilla ones.
Dave
Allerdings verstehe ich immer noch nicht, weshalb Du nicht einfach ANPM/YUM nimmst, das wird doch sowieso die "Zukunft" unter OS/2.

Und mit den ganzen Linux-Abhängigkeiten wird das ohne funktionierendes Paket-Management zukünftig auch nicht mehr handhabbar sein.
Grüße,

Thorolf
Benutzeravatar
thorolf
Beiträge: 563
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Hallo allerseits,

ich habe nun auf meinem T60 mit eCS 2.2beta den neuen FF 38esr installiert, wieder wie oben beschrieben mittels ANPM und RPM für die Libs und dann das WPI von Firefox. Hat soweit alles geklappt, alle Plugins wurden, von Firefox 3.6 kommend korrekt aktualisiert, ebenso das Sprachpaket und die Dictionary's.

Verloren "gegangen" sind diesmal allerdings alle Lesezeichen und die "vorherige Sitzung", die muss ich also irgendwie aus dem alten Profil wieder importieren, der Start ist immer noch recht "träge", zur Stabilität und weiteren Kompatibilität kann ich aber nichts weiter sagen.

Hat in Summe etwa eine halbe Stunde gebraucht, ich habe diesmal außerdem ein paar Neustarts weggelassen, für die Installation eines Web-Browser ist das natürlich inakzeptabel, aber das beinhaltete ja auch noch ANPM/YUM und einige extra Libs, die, sobald es Firefox als RPM gibt, automatisch aktualisiert werden sollten.

Nervig (und völlig unabhängig von Firefox) ist auf dem T60p mit C2D allerdings, das der Lüfter dauerhaft läuft und die Temperatur meist bei 70°C liegt, da ist der ACPI also noch weit entfernt von "gut genug".


Edit:
Doof, die Bookmark-Backups von FF 3.6 sind wohl inkompatibel zum 38esr, der Zwischenweg über FF 10 geht nicht, weil irgendeine "MOZFNTCFG" fehlt und der sich nicht installieren lässt.
Grüße,

Thorolf
Benutzeravatar
MikeK
Beiträge: 369
Registriert: Mo 23. Dez 2013, 13:51
Wohnort: Potsdam

Beitrag von MikeK »

Hallo Thorolf,

kopiere mal die "places.sqlite" aus dem alten Profil ins Neue, dann sollten die Lesezeichen (hoffentlich) alle da sein.

Mein persönliches Gefühl ist (nicht nachgemessen), dass der Feuerfuchs 38.2.1 deutlich schneller startet. Aber er ist mir schon mehrmals beim Laden von Webseiten gecrasht. Im Trap-Record steht immer die "pmmerge.dll" als Modul, welches den Trap verursacht. Ansonsten macht der neue FF einen guten Eindruck.

Nach meinem dafürhalten sind die alten Peter Weilbacher Builds (PmW-FF 2er Serie) immer noch die die am schnellsten laden. Allerdings werden da eben neuere Web-Technologien nicht unterstützt.

Grüße aus Potsdam,
Mike
Beat

Beitrag von Beat »

Guten Tag Zusammen

ich habe die entsprechenden Packe die ich mit yum wie angegeben von
Jörg Rustmeier installiert und anschliessend ganz herzlos die *.wpi Datei
über die bestehende (Firefox 17 xxx) Installation gelegt.

Klich auf das vorhandene Icon und Firefox startet ohne zu mekern...

BS: eCs Version 2.2

Gruss und Dank an alle
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

thorolf » Mi 24. Feb 2016, 12:34 hat geschrieben: Verloren "gegangen" sind diesmal allerdings alle Lesezeichen und die "vorherige Sitzung", die muss ich also irgendwie aus dem alten Profil wieder importieren, der Start ist immer noch recht "träge", zur Stabilität und weiteren Kompatibilität kann ich aber nichts weiter sagen
...

Edit:
Doof, die Bookmark-Backups von FF 3.6 sind wohl inkompatibel zum 38esr, der Zwischenweg über FF 10 geht nicht, weil irgendeine "MOZFNTCFG" fehlt und der sich nicht installieren lässt.
Die README.OS2 beschreibt zwar die Änderung des Datenbankformates, welche ab FF 4.0 stattgefunden hat. Allerdings wird verschwiegen, daß der Kode zur Konvertierung (bzw. Migration) in den letzten Versionen entfernt wurde. Wenn ich mich recht erinnere, war es bereits im letzten Jahr. Als Umweg wurde Sync vorgeschlagen. Einfacher ist es natürlich in FF 3.6 die Lesezeichen nach HTML zu exportieren und im neuen Programm zu importieren.

Für dein FF 10 Problem benötigst du beim Einsatz von RPM das freetype-legacy Paket, oder/und die Sammlung der DLLs auf welche ich in der Seamonkey-Mitteilung verwiesen habe.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

ak120 » Mi 24. Feb 2016, 15:21 hat geschrieben: Für dein FF 10 Problem benötigst du beim Einsatz von RPM das freetype-legacy Paket, oder/und die Sammlung der DLLs auf welche ich in der Seamonkey-Mitteilung verwiesen habe.
Das kann ich bestätigen. Eigentlich wird es mitinstalliert mit dem aktuellsten freetype. Anscheinend gilt das aber nicht, wenn man vorher z.B. nur das Posix-Subsystem installiert hat, das eCS 2.2 beta 2 mitbringt.

Zusätzlich hat sich auch noch fontconfig erneuert. (OT: Mit einer alten Mozille funktioniert bei mir mit mit der neuen fntcfg2.dll die Schriftglättung nicht mehr. Vielleicht hilft's ja jemandem.)
Andreas Schnellbacher
os2guenni
Beiträge: 270
Registriert: Di 8. Apr 2014, 10:22
Wohnort: Fürstenberg/Weser

Beitrag von os2guenni »

Hallo zusammen,
ich möchte nicht unbedingt einen neuen Eintrag aufmachen.
Habe die FF Beta Version installiert - wenn ich sie starte, werkelt er ein wenig im Hintergrund , startet mir aber nicht das Pgm.
Ansonsten keine Fehlermeldung, nur im Popuplog ist folgende Meldung SYS2070 "xul > MOZALLOC._moz_malloc_size_ of 127".
Was besagt diese Meldung?

Gruß
Günter
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Hier ist nicht der geeignete Ort um Fehlerbehebung an einem bestimmten Programm (firefox) zu betreiben. Mit den wenigen Angaben kann man meist nur Vermutungen anstellen und keine anständige ernsthafte Analyse. Also bitte zuerst die README.OS2 lesen, auch wenn die Aussagen dort etwas ungenau und nicht immer zutreffend sind, dann erübrigen sich solche Fragen an dieser Stelle.
Antworten