Yum AOO 4.1.3 und FF 38.8b8

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Antworten
MarcSenn

Yum AOO 4.1.3 und FF 38.8b8

Beitrag von MarcSenn »

Also Das Problem ist Yum
Yum installiert
den yum gestartet
auf der cmd yum install libc libgcc1 libgcc-fwd openssl curl libjpeg libxslt libicu zlib libxml2 mmap pthread urpo libstdc++6 libstdc++ gestartet für AOO

AOO Läuft

Wenn ich jetzt wider yum eingebe kommt
Fehler: dbiOpen: dbapi 1 not available
Fehler: Paket-Datenbank in /@unixroot/var/lib/rpm kann nicht geöffnet werden
Traceback (most recent call last):
  File "D:\TMP\YUMBT\USR\BIN\YUM", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/@unixroot/usr/share/yum-cli/yummain.py", line 288, in user_main
    errcode = main(args)
  File "/@unixroot/usr/share/yum-cli/yummain.py", line 98, in main
    base.getOptionsConfig(args)
  File "/@unixroot/usr/share/yum-cli/cli.py", line 230, in getOptionsConfig
    self.conf
  File "D:/tmp/yumbt/usr/lib/python2.7/site-packages/yum/__init__.py", line 781,
 in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "D:/tmp/yumbt/usr/lib/python2.7/site-packages/yum/__init__.py", line 258,
 in _getConfig
    startupconf = config.readStartupConfig(fn, root)
  File "D:/tmp/yumbt/usr/lib/python2.7/site-packages/yum/config.py", line 839, i
 n readStartupConfig
    startupconf.releasever = _getsysver(startupconf.installroot, startupconf.dis
troverpkg)
  File "D:/tmp/yumbt/usr/lib/python2.7/site-packages/yum/config.py", line 949, i
n _getsysver
    idx = ts.dbMatch('provides', distroverpkg)
_rpm.error: rpmdb open failed
ist nicht kommplet weil eine >text.txt um dne fehler in eien datei zu schreiben geht nicht datei bleibt leer.

Da get den auch kein yum install libstdc++6 nspr nss libicu pixman cairo pango fontconfig freetype libkai mher
für FF 38.8


Also vm neu gemacht
yum frisch installiert gibt den help m Scren aus
yum install libstdc++6 nspr nss libicu pixman cairo pango fontconfig freetype libkai für FF.

Jetzt läuft FF 38.8
Aber wider der selbe fehler wenn ich den
yum install libc libgcc1 libgcc-fwd openssl curl libjpeg libxslt libicu zlib libxml2 mmap pthread urpo libstdc++6 libstdc++ eingeben für die DLLs für AOO.

Irgent wie killt sich Yum selber egal ob ich zuerst die FF oder zuerst das AOO DLL Paket installiere?

Arg Nerft so, hab keine zeit zum Basteln. :x
Zuletzt geändert von MarcSenn am Sa 4. Feb 2017, 11:47, insgesamt 1-mal geändert.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Nein, das Problem sind neben alten und fehlerhaft gepackten .rpm-Paketen auch irgendwo im LIBPATH zu findende Uralt-DLLs gleichen Namens, die DLL-Hölle also. Fast immer reicht es schon, die alten DLLs aus \ecs\dll umzubennen oder zu löschen. YUM hat zwar auch Fehler, aber andere.

Für den Endanwender ist das ziemlich egal. Er kommt dann nicht weiter und ist genervt. Direkte Hilfe dabei gibt es nicht.

Hilfreich ist diese Arca-Noae-Seite. In Zukunft, mit Arca OS, werden diese Probleme natürlich so nicht mehr auftreten. Bis dahin ist zusätzlich zu dem genannten Link noch zu empfehlen ANPM zu installieren, am besten die noch unveröffentlichte Version 1.0.1, sonst auch die offizielle letzte Version.
Zuletzt geändert von aschn am Sa 4. Feb 2017, 13:10, insgesamt 1-mal geändert.
Andreas Schnellbacher
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Die Probleme lassen sich ja noch umschiffen. Unkomplizierter schneller (und vor allem stabiler) ist es, die Dateien aus dem mozsupport Archiv (gibt es unter http://os2news.warpstock.org/Warpzilla.html) im Programmverzeichnis (oder über BEGINLIBPATH) zu verwenden. Eine RPM-Portierung, welche auch tatsächlich einigermaßen funktionieren würde, kann man unter OS/2 natürlich nicht erwarten. Das Programm rpm selbst kommt nicht mal mit OS/2-typischen Pfaden klar, also Rückstrich bzw. Yen-Zeichen.
MarcSenn

Beitrag von MarcSenn »

Genau darum würde ich es schön finden das in jedem Install Ordner noch alle DLL sind wo man für diese Anwendungen braucht wo man den nur noch verteilen muss.
anpm installiert mal schauen.
Aua öm und wie findet man die repositorys?

PS:Und nochmals neu die vm weil deinstallieren geht ja nicht weil yum spinnt.
Den mit Yum die dll für AOO installieren udn von hand die für FF 38.8

Grins und ihr sagt Windows sei schlimmer. ;-) als Stunden lang herum basteln.
Zuletzt geändert von MarcSenn am Sa 4. Feb 2017, 20:06, insgesamt 4-mal geändert.
MarcSenn

Beitrag von MarcSenn »

Uff geht jetzt entlich Archa noae Manager läuft ja wider.
Hat vieles geupdatet aber AOO udn FF lief immer noch nicht, also mal jede einzelne lib wo im yum angegeben werden müssten für Aoo und FF im Manager gesucht und ein paar waren nicht installiert also jedes dll installiert wo noch uninstalliert war.
Und ja endlich AOO und FF 38.8 läuft, aber nicht gerade Userfreuntlich.
Wie gesagt ich würde bei jedem AOO und FF ein Ordner machen wo eine wpi drin ist wo alles installiert was AOO oder auch FF braucht, das wäher schon Userfreuntlicher.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Wie gesagt ich würde bei jedem AOO und FF ein Ordner machen wo eine wpi drin ist wo alles installiert was AOO oder auch FF braucht,
Mach das wenn Das wenn du willst. Ist ja alles frei verfügbar. Nur zu. Aber offensichtlich hast du keine Ahnung, welche Probleme du dir damit einhandelst. Ich werde das jetzt nicht mehr hier wiederholen weil es eh schon zig mal diskutiert wurde. Wie und wann welche dll bei OS/2 geladen und entladen wird und was alles für blöde Probleme entstehen wenn man, wie nach deinem Vorschlag, verschiedenste Versionen einer dll auf dem System hat.

Wie gesagt, mach das was du da vorschlägst und falle selbst auch noch mal auf die Nase. Aber lass deine wpis bitte nicht auf andere User los.
Benutzeravatar
Sepp Mayr
Beiträge: 150
Registriert: Mo 13. Jan 2014, 11:28
Wohnort: Bayern, oda wos hobt ihr dachd?
Kontaktdaten:

Beitrag von Sepp Mayr »

So nebenbei, nach update einiger Pakete über ANPM startet FF 38.8 bei mir nicht mehr (xul.dll fehlt). Noch keine Ursachenforschung getätigt.
Mia san mia
eCSBenutzer
Beiträge: 457
Registriert: Fr 10. Jan 2014, 07:24
Wohnort: 641m ü. NN

Beitrag von eCSBenutzer »

Welche Pakete? Nicht das ich in die Falle auch reintappe ;)
MarcSenn

Beitrag von MarcSenn »

Andi B. hat geschrieben:
Wie gesagt ich würde bei jedem AOO und FF ein Ordner machen wo eine wpi drin ist wo alles installiert was AOO oder auch FF braucht,
Mach das wenn Das wenn du willst. Ist ja alles frei verfügbar. Nur zu. Aber offensichtlich hast du keine Ahnung, welche Probleme du dir damit einhandelst. Ich werde das jetzt nicht mehr hier wiederholen weil es eh schon zig mal diskutiert wurde. Wie und wann welche dll bei OS/2 geladen und entladen wird und was alles für blöde Probleme entstehen wenn man, wie nach deinem Vorschlag, verschiedenste Versionen einer dll auf dem System hat.

Wie gesagt, mach das was du da vorschlägst und falle selbst auch noch mal auf die Nase. Aber lass deine wpis bitte nicht auf andere User los.
Also bis jetzt läuft alles noch, sogar ObjectDesktop 2.0. ^^
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Sepp Mayr hat geschrieben: nach update einiger Pakete über ANPM startet FF 38.8 bei mir nicht mehr (xul.dll fehlt)
Du hast dann mit Sicherheit noch nicht in \ecs\dll aufgeräumt, wie es Lewis auf der von mir genannten Seite beschrieben hat.

Ich würde erstmal alles, was auch in %UNIXROOT%\usr\lib vorhanden ist, umbenennen. Neben allen gcc*.dll und libc*.dll sind das z.B.: ssp.dll, stdcpp.dll und supcpp.dll. Bei den restlichen kann ich nicht mehr nachsehen, weil ich sie gelöscht hab. Die genannten sollte aber jeder entfernen. Falls ältere Anwendungen dann nicht mehr laufen, dann installiert man einfach die entsprechenden *legaecy-Pakete hinzu, die etliche Versionen mit älterem Dateinamen mit bringen, aber selbst nur auf die aktuelle verweisen.

Zum automatisierten Umbenennen kann ich dllcleanout.cmd aus diesem Thread empfehlen
Andreas Schnellbacher
Benutzeravatar
Sepp Mayr
Beiträge: 150
Registriert: Mo 13. Jan 2014, 11:28
Wohnort: Bayern, oda wos hobt ihr dachd?
Kontaktdaten:

Beitrag von Sepp Mayr »

eCSBenutzer hat geschrieben:Welche Pakete? Nicht das ich in die Falle auch reintappe ;)
Eigenwillig, heute gehts wieder. Keine Ahnung was da war.
Ansonsten wirft dies die Frage auf wo find ich die Info zu den letztens installierten Paketen?
Die Auswahl "Kürzlich aktualisierte Pakete" im ANPM und danach Klick auf den Neu Laden (Reload) -Button bringt nur gähnende Leere im ANPM.
Irgendwelche *.rpm-Pakete finde ich auch nirgendwo auf der Festplatte.
In X:\var\log\yum.log dann dieses gefunden:

Feb 12 19:46:55 Updated: os2-base-0.0.0-14.oc00.i686
Feb 12 19:46:56 Updated: libvpx-1.4.0-2.oc00.i686
Feb 12 19:47:00 Updated: ncurses-base-5.9-1.oc00.i686
Feb 12 19:47:01 Updated: ncurses-libs-5.9-1.oc00.i686
Feb 12 19:47:04 Updated: ncurses-5.9-1.oc00.i686
Feb 12 19:47:06 Updated: libvpx-devel-1.4.0-2.oc00.i686

Aber wie oben geschrieben, ging heute nach Rechner anwerfen wieder.
Mia san mia
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Was hälts Du davon:

Auf Deinem System ist eine dieser System-DLLs in einem Anwendungsverzeichnis vorhanden. Du hast diese Anwendung gestartet und damit auch diese System-DLL geladen. Mozilla startet deshalb nicht, weil es diese System-DLL mit gleichem Namen auch benötigt, aber eine ältere bereits geladen ist. Mit OS/2 gibt es dann zwei Möglichkeiten: 1) Die zuerst gestartete Anwendung schließen. Damit wird auch die DLL wieder entladen. 2) LIBATHSTRICT verwenden und sich so den knappen Shared-Memory-Speicher kürzen, ... bis gar nichts mehr geht.

Während ich dies schreibe, denke ich, dass der wahrscheinlichste Grund bei Dir zu knapper Shared-Memory-Bereich war. Hast Du eigentlich mit highmem.exe die Mozilla-DLLs hochladbar gemacht?
Andreas Schnellbacher
Benutzeravatar
Sepp Mayr
Beiträge: 150
Registriert: Mo 13. Jan 2014, 11:28
Wohnort: Bayern, oda wos hobt ihr dachd?
Kontaktdaten:

Beitrag von Sepp Mayr »

aschn hat geschrieben:Während ich dies schreibe, denke ich, dass der wahrscheinlichste Grund bei Dir zu knapper Shared-Memory-Bereich war. Hast Du eigentlich mit highmem.exe die Mozilla-DLLs hochladbar gemacht?
Danke für die Hinweise. Doppelte dll habe ich nicht gefunden. Die Sache mit highmem ist aber eine durchaus denkbare Sache, habe ich bisher noch nicht gemacht.
Mia san mia
Antworten