[Gelöst]Hätte gerne xpat2 für openSuSe 13.2

[gm2601]

Hallo Gurus,

ich weiß, danach habe schon einmal gefragt und die letzte Version, bei der ich es zum Laufen brachte ist 11.3, dennoch scheitern alle meine Versuche unter 13.2. Das mag durchaus daran liegen, dass ich mit Sourcepaketen keinerlei Ahnung, aber auch mit rpm so manche Probleme habe.

Nun habe ich hier "ftp://ftp.tu-freiberg.de/pub/sgi/freeware/fw-6.2/Dist/" eine Datei "fw_xpat2-1.04.tardist" gefunden, die ich via try&err zum Laufen bekam, leider ohne Kartenset. Kann ich ein Kartenset vom installierten PySol einbinden und wenn ja, wie, oder erbarmt sich einer von euch mir beim installieren eines src.rpm unter die Arme zu greifen.

Ein rpm -qa sieht "xpat2-1.07-40.1.x86_64", es ist startbar aber eben ohne Karten.

Bei den von rpmseek angebotenen scheitere ich an "...nothing provides xorg-lib-libXt" :???:


Danke im voraus

 

[josef-wien]

Einen noch funktionierenden Spiegelserver von 9.3 habe ich über http://rpm.pbone.net/index.php3/stat/2/simple/2 gefunden: ftp://bo.mirror.garr.it/pub/1/suse/discontinued/i386/9.3/suse/x86_64/xpat2-1.07-795.x86_64.rpm

Das Paket läßt sich bei 13.1 problemlos installieren, auf Grund der Abhängigkeiten sollte das auch bei 13.2 der Fall sein.

Mit ist die Gnome 2-Version von aisleriot aus 11.4 trotzdem lieber.

 

[gm2601]

Danke Josef,

es wäre ja zu schön gewesen, aber die ftp-Quelle endet mit:

nothing provides libstdc++.so.5()(64bit) needed by xpat2-1.07-795.x86_64

Nun behauptet webpin

   20 results (5 packages) found for "libstdc++.so.5" in openSUSE_132
* libstdc++33-32bit: The standard C++ shared library
   - 3.3.3.32.1 [home:cornelisbb | home:lackhove]
   - 3.3.3.32.3 [home:badshah400:branches:devel:gcc]
   - 3.3.3.41.2.1 [home:srinidhi:branches:openSUSE:13.1:Update]
* libstdc++33-doc: Documentation for the GNU C++ standard library
   - 3.3.3.41.2.1 [home:srinidhi:branches:openSUSE:13.1:Update]
   - 3.3.3.32.1 [home:cornelisbb | home:lackhove]
   - 3.3.3.32.3 [home:badshah400:branches:devel:gcc]
* libstdc++33: The standard C++ shared library
   - 3.3.3.32.1 [home:lackhove | home:cornelisbb]
   - 3.3.3.32.3 [home:badshah400:branches:devel:gcc]
   - 3.3.3.41.2.1 [home:srinidhi:branches:openSUSE:13.1:Update]
* mingw32-libstdc++6: MinGW Windows compiler for C++ shared libraries
   - 4.9.2.2.1 [home:ecsos:pipelight | home:deltafox]
   - 4.8.3.13.1 [windows:mingw:win32 | home:ecsos:pipelight]
   - 4.9.2.4.2 [home:Ximi1970:Toolchains:MinGW:latest:win32]
* Mesa-libGLESv2-2: Free implementation of the OpenGL|ES 2.x API
   - 10.3.2.410.1 [X11:XOrg]
   - 10.4~git20141101.1.3 [home:pontostroy:X11]
   - 10.3.1.407.1 [home:derselbst]
   
   ......................
   
   rpm -qa | grep libstdc++
libstdc++-devel-4.8-7.1.2.x86_64
libstdc++6-32bit-4.8.3+r212056-2.2.4.x86_64
libstdc++48-devel-4.8.3+r212056-2.2.4.x86_64
libstdc++6-4.8.3+r212056-2.2.4.x86_64
libstdc++6-debuginfo-4.8.3+r212056-2.2.4.x86_64

..............................rpm -ql libstdc++6xxxx 
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.19

ein copy von /usr/lib64/libstdc++.so.6 nach /usr/lib64/libstdc++.so.5 brachte selbst nach einem reboot nichts. Da steh ich nun.... :???:

aisleriot habe ich via yast2 (ohne Probleme!!) installiert, aber da mir das unbekannt ist muss ich mich erst noch damit auseinandersetzen.

 

[josef-wien]

Binde das oss-Repo von 13.1 kurz mit Priorität 100 ein, markiere "Heruntergeladene Pakete nicht löschen", und hebe Dir nach der Installation das in /var/cache/zypp/packages/... enthaltene Paket libstdc++33 gut auf.

Alternativ kannst Du Dir das Quell-Paket von xpat2 holen und als Benutzer mit

rpmbuild --rebuild xpat2-1.07-795.src.rpm

übersetzen, das "normale" Paket findest Du danach in ~/rpmbuild/RPMS/x86_64. Was zum Übersetzen notwendig ist, zeigt Dir:

rpm -qRp xpat2-1.07-795.src.rpm

ein copy von /usr/lib64/libstdc++.so.6 nach /usr/lib64/libstdc++.so.5 brachte selbst nach einem reboot nichts.

Das nützt selbst dann nicht, wenn die Bibliothek für den Zweck brauchbar wäre. Was ein Paket benötigt, muß in einem anderen Paket enthalten sein (und nicht bloß als Datei im Dateisystem; es gibt übrigens auch Anforderungen, die nichts mit einer Datei zu tun haben).

 

[gm2601]

Danke Josef,

"Was ein Paket benötigt, ..." stellte sich ganz flugs durch die beiden von Dir genannten Befehle heraus. Bei "rpmbuild" kamen 40, bei "rpm -qRp" 115 Zeilen, was auch noch da sein sollte.

Vermutlich habe ich doch die falsche Reihenfolge gewählt und hätte mit dem Repo anfangen sollen. Heute wird das aber nicht mehr in Angriff genommen, dazu ist das Wetter einfach zu schön.

 

[abgdf]

Ich finde, PySol macht das auch nicht schlecht.

 

[gm2601]

Ich finde, PySol macht das auch nicht schlecht.

Das ist für mich die zweite Wahl, falls ich bei meinen Versuchen zu xpat2 endgültig scheitere.

 

[gm2601]

Binde das oss-Repo von 13.1 kurz mit Priorität 100 ein, markiere "Heruntergeladene Pakete nicht löschen", und hebe Dir nach der Installation das in /var/cache/zypp/packages/... enthaltene Paket libstdc++33 gut auf.

Hallo Josef,

nun habe ich in yast
http://download.opensuse.org/distribution/13.1/repo/oss/
enabled, Prio=100, keep downloades

und gehofft per search xpat2 erfolgreich zu sein, aber "no results", womit sich eine Installation nicht mehr anbietet.
Die "libstdc++33-3.3.3-41.1.3.x86_64" wird übrigens von rpm als installiert gesehen.

Wo liegt mein Denkfehler, bzw. was kann ich weiterhin tun?

 

[revealed]

Kann es sein, dass er die 32 bit version der Datei haben möchte, obwohl es (64) geflagt wurde in der Ausgabe?

Gruß,

R

 

[josef-wien]

nothing provides libstdc++.so.5()(64bit) needed by xpat2-1.07-795.x86_64

Wie hast Du damals die Installation von xpat2 versucht? Jetzt probierst Du es offenbar anders.

"libstdc++33-3.3.3-41.1.3.x86_64" wird übrigens von rpm als installiert gesehen.

Dann dürfte es obige Fehlermeldung nicht gegeben haben.

Kann es sein

Nein.

 

[gm2601]

Das war der Versuch nach

Einen noch funktionierenden Spiegelserver von 9.3 habe ich über http://rpm.pbone.net/index.php3/stat/2/simple/2 gefunden: ftp://bo.mirror.garr.it/pub/1/suse/discontinued/i386/9.3/suse/x86_64/xpat2-1.07-795.x86_64.rpm

den ich zwischenzeitlich wiederholte, bei dem nun aber nicht mehr die genannte Fehlermeldung kommt sondern "unbekannter Status", danach "Installation aborted by user" und da irrt sich Apper.
Wenn libstdc++.so.5()(64bit) dasselbe ist wie das

rpm -ql libstdc++33-3.3.3-41.1.3.x86_64
/usr/lib64/libstdc++.so.5
/usr/lib64/libstdc++.so.5.0.7

dann hätte es eigentlich gehen sollen.

Welcher Versuch mit try&err bei fw_xpat2-1.04.tardist, der xpat2 ohne Karten startete, weiß ich nicht mehr, dort sind in erster Ebene folgende files/Dir:

debian diff.noroot diff.noxpm doc etc lib makecards Makefile README src successful und insgesamt >500 Dateien enthalten.


aisleriot habe ich mir mittlerweile angesehen, es nähert sich in seiner Bedienfreundlichkeit dem xpat2 recht gut an, dennoch will ich die Flinte noch nicht ins Korn werfen.

 

[josef-wien]

Falls es noch nicht erfolgt ist, xpat2-1.07-795.x86_64.rpm herunterladen und speichen. Dann im entsprechenden Verzeichnis

zypper in xpat2-1.07-795.x86_64.rpm

ausführen. Wenn es Probleme gibt, Befehl und Ergebnis zeigen.

Wenn libstdc++.so.5()(64bit) dasselbe ist

rpm -q --whatprovides "libstdc++.so.5()(64bit)"
rpm -ql --provides libstdc++33

 

[gm2601]

Wenn es Probleme gibt, Befehl und Ergebnis zeigen.

# zypper in xpat2-1.07-795.x86_64.rpm
Timeout exceeded when accessing 'http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_13.2/repodata/repomd.xml'.

Ein Ping auf ftp.gwdg.de wird beantwortet, aber sagtest Du nicht, das sei auf einem 9er Repo, warum sucht zypper dann in 13.2? Kann das etwas mit dem noch aktiven 13.1 Repo mit Prio 100 zu tun haben? Vorstellen kann ich mir das nicht so recht.
Ein zweites md5sum-identisches rpm von http://suse.cs.utah.edu/i386/9.3/suse/x86_64/ bringt jedoch die gleiche Meldung.

# rpm -q --whatprovides "libstdc++.so.5()(64bit)"
libstdc++33-3.3.3-41.1.3.x86_64
# rpm -ql --provides libstdc++33
compat-libstdc++
libstdc++.so.5()(64bit)
libstdc++.so.5(CXXABI_1.2)(64bit)
libstdc++.so.5(CXXABI_1.2.1)(64bit)
libstdc++.so.5(CXXABI_1.2.2)(64bit)
libstdc++.so.5(GLIBCPP_3.2)(64bit)
libstdc++.so.5(GLIBCPP_3.2.1)(64bit)
libstdc++.so.5(GLIBCPP_3.2.2)(64bit)
libstdc++.so.5(GLIBCPP_3.2.3)(64bit)
libstdc++.so.5(GLIBCPP_3.2.4)(64bit)
libstdc++.so.5(GLIBCPP_3.2.5)(64bit)
libstdc++33 = 3.3.3-41.1.3
libstdc++33(x86-64) = 3.3.3-41.1.3
libstdc++5 = 3.3.3-41.1.3
/usr/lib64/libstdc++.so.5
/usr/lib64/libstdc++.so.5.0.7

Nachtrag:
Siehe da, die Benachrichtigung in der Kontrollleiste bringt dieselbe timeout Meldung ganz ungefragt , ergo später nochmal versuchen.

 

[josef-wien]

Das bei Dir definierte Packman-Repo funktioniert (derzeit) nicht, daß Du es in diesem Fall gar nicht brauchst, spielt dabei keine Rolle. Trage einen anderen Spiegelserver aus http://packman.links2linux.de/mirrors ein.

 

[gm2601]

Danke Josef!

Es ist vollbracht!!
Nachdem ich das hängende Repo disabled habe, aber mich beschleicht der Verdacht, dass mich die Problematik bei >13.2 (42.x?) wieder einholt, denn noch ist mir der Zusammenhang warums nicht ging, bzw. jetzt geht nicht wirklich klar.

 

[josef-wien]

Jetzt funktioniert es, weil alle Anforderungen des Pakets xpat2-1.07-795.x86_64.rpm erfüllt sind. Speichere diese Datei sowie libstdc++33-3.3.3-41.1.3.x86_64.rpm in einem Verzeichnis, und binde dieses als lokales Repo ein. Gegebenenfalls mußt Du bei einem künftigen Release-Wechsel wieder ein nicht mehr enthaltenes Paket von der früheren Release "organisieren" und im lokalen Repo zur Verfügung stellen. Die primären Kandidaten kannst Du jetzt schon mit

rpm -q --requires xpat2 | while read "req" ; do rpm -q --whatprovides "$req" ; done | grep -v rpmlib | sort -u

finden, wobei die jeweilige Version nicht von Bedeutung ist.

Solange es keine grundlegenden Änderungen beim X-Server gibt, sollte xpat2 meiner Meinung nach funktionieren.

 

[gm2601]

Hallo Josef,

Du sagst ganz locker:

Speichere diese Dateien in einem Verzeichnis, und binde dieses als lokales Repo ein.

dabei ist Repos erweitern bei mir immer mit etlichen Anläufen verbunden, aber ein Verzeichnis habe ich bisher noch nie eingebunden. ps:
Dennoch ist es gleich bei der Premiere erstaunlich problermlos gelungen.

Ich sollte also, wenn ich Dich richtig verstanden habe, mit folgenden Dateien künftig mit xpat2 keine Probleme mehr haben,

bash-4.2-75.3.1.x86_64.rpm
glibc-devel-2.19-16.15.1.x86_64.rpm
libgcc_s1-4.8.3+r212056-2.2.4.x86_64.rpm
libstdc++33-3.3.3-41.1.3.x86_64.rpm
libXpm4-3.5.11-4.1.2.x86_64.rpm
qt3-3.3.8c-135.1.3.x86_64.rpm
xpat2-1.07-795.x86_64.rpm

denn das sind die, die Dein ellenlanges Kommando hervorbrachte. Nur bei glibc habe ich lediglich die devel-version gefunden, aber das ist doch eher eine Übermenge der glibc.(?)

 

[josef-wien]

Nur bei glibc habe ich lediglich die devel-version gefunden

Das kann nicht sein, ohne glibc würde Dein Linux gar nicht funktionieren. bash, glibc und vermutlich libgcc_s1 können wir ausklammern.

Bei den übrigen beiden Paketen libXpm4 und vor allem qt3 könnte es sein, daß sie in einer künftigen openSUSE-Release nicht mehr enthalten sind, dann mußt Du auf die Pakete der vorhergehenden Release zurückgreifen (vor allem bei qt3 durch kurzzeitiges Einbinden der alten Repos, da hier vermutlich auch Abhängigkeiten zu installieren sind).

 

[gm2601]

Das kann nicht sein, ohne glibc würde Dein Linux gar nicht funktionieren

Vielleicht reden wir gerade aneinander vorbei, "glibc" finde ich hundertfach, aber exakt die, die Dein langes Kommando "rpm -q --requires xpat2....." auflistet, die "glibc-2.19-16.15.1.x86_64" finde ich als rpm nicht, der kommt die "glibc-devel-2.19-16.15.1.x86_64.rpm" m.E. am nächsten.
Alle anderen habe ich nun in exakt dem Release Deines "rpm -q --requires xpat2....." in dem Verzeichnis, das mir nun auch als Repo dienen kann und mit dem ich hoffe, auch in weiteren openSuSe-Versionen xpat2 zum laufen zu bringen.

Wenn nicht, dann ist mein Vertrauen in Dich groß.

Danke nochmal!

 

[gehrke]

Es ist vollbracht!!
Nachdem ich das hängende Repo

Die Verwendung von size-Tags führt bei mir dazu, dass ich den zweiten Teil quasi gar nicht lesen kann, solange ich es nicht bewusst im Browser hochskaliere. Ich vermute, das war anders geplant?!?