• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Telefonanlagenserver Agfeo Tk Suite auf opensuse

Znarf

Member
Halo Linuxgemeinde,

ich hatte auf einem älteren opensuse 11.4 64bit seit vielen Jahren problemlos einen Telefonanlagenserver (Tk Suite Server) und Client betrieben, der über den Browser verwaltet wird.
Anlage: Agfeo AS40, mit dem Rechner über serielle Schnittstelle verbunden (CAPI ISDN funktionierte noch nie)
Software: Tk Suite Professional Server und Client für Linux 4.2.12
Dienst (Runlevel 2,3,5) tksuitectl (keine Fehlermeldungen)

Die Serveranmeldung erfolgt normal mit http://127.0.0.1:5080/über einen Browser.

Letzte Woche ging die Anmeldung von einem Tag auf den anderen nicht mehr (Fehlermeldung
...kann keine Verbindung zu dem Server unter 127.0.0.1:5080 aufbauen.
.

Konfigurationsänderungen am System habe ich nicht vorgenommen (Firewall, Router...)

Telnet gibt folgendes aus
telnet serverip 5080
telnet: serverip: Name or service not known

Mit netstat -a erscheint der 5080 Port nicht (mehr).

Ich habe schon die Agfeo-Hilfeforen durchgeschaut, leider ohne Erfolg.

Ach ja, die Telefonanlage läuft sonst einwandfrei, aber ich kann sie eben nicht mehr steuern!

Wäre schön, wenn jemand einen Tipp für mich hätte
 
OP
Z

Znarf

Member
Nachtrag
Hab aud dem Rechner virtuelles Win XP, hier klappt die Verbindung zum Port 5080 (kann aufgerufen werden), allerdings ist die Schnittstelle (com1) ebenfalls nicht erreichbar.
Einen "nativen" Windowsrechner hab ich leider nicht verfügbar, um es ausprobieren zu können.

Gruß Z.
 
OP
Z

Znarf

Member
Hallo Opensuse Freunde

bin jetzt bei dem Problem insofern weitergekommen, dass ich nun weiß, dass definitiv kein Hardwarefehler der Telefonanlage vorliegt. Mit einem Win7 Laptop konnte ich über die serielle Schnittstelle einwandfrei auf das Webinterface der Anlagenkonfiguration zugreifen.

Linuxseitig funktioniert der Zugriff auf das Webinterface schon nicht
Code:
Firefox kann keine Verbindung zu dem Server unter 127.0.0.1:5080 aufbauen.

Ich habe leider keine Ahnung, warum der Port nicht mehr zugänglich ist, die Funktion war - nachdem das jetzt so genau 10 Jahre unverändert und erfolgreich lief - von einem Boot des Rechners auf den nächsten nicht mehr vorhanden.

Hat jmd. vielleicht einen Tipp, wie man herausfinden kann, warum der Port nicht mehr zugänglich ist. An einen Defekt der Hardware (serielle Karte) glaube ich nicht, weil das Problem genauso bestehen bleibt, wenn ich das serielle Kabel aus der Anlage mit einem USB-Adapter an den Rechner anschließe und die Schnittstelle anpasse
Code:
mv /dev/ttyS3 /dev/ttyS3~
anschließend
Code:
ln -s /dev/ttyUSB0 /dev/ttyS3
und
Code:
chmod 666 /dev/ttyUSB0
. P.S. Ist klar, dass das beim Reboot überschrieben würde!

Firefoxeinstellungen schließe ich ebenfalls aus, da unter Konqueror dasselbe Problem besteht. Firewall habe ich keine laufen, am Router (FB 7360) habe ich seit sicher 1/2 Jahr keine Änderungen vorgenommen, ebensowenig am Netzwerk.

Wäre super, wenn vielleicht doch noch jmd. einen Gedankenblitz hätte.

Danke Z.
 
OP
Z

Znarf

Member
Hallo Leute

die Resonanz ist ja nicht gerade überwältigend, aber die Hoffnung stirbt zuletzt. Das Problem kann ich mittlerweile klar eingrenzen, die Telefonanlage ist in Ordnung.

Offensichtlich stürzt das Programm tksock kurz nach dem Laden ab

Code:
/usr/local/tksuite_server # TK-Suite-Server (c) 2009 AGFEO GmbH & Co. KG Version 4.2.12
This product uses parts of the SFL package
Copyright (c) 1996-2000 iMatix Corporation
1991-2000 iMatix Corporation <http://www.imatix.com>.
This product uses parts of the SMT Kernel
Copyright (c) 1991-2000 iMatix Corporation
This program uses SQLite <http://www.sqlite.org/copyright.html>
This program uses technology developed by saltation <http://www.saltation.de>
tkmedia: symbol lookup error: /usr/lib/capi/lib_capi_mod_std.so: undefined symbol: get_buffer
shutting down...

Der Aufruf des Dienstes
Code:
/usr/local/tksuite_server # /etc/init.d/tksuitectl start
/etc/init.d/tksuitectl start: starting tksock...
/etc/init.d/tksuitectl start: tksock started
scheint zunächst erfolgreich zu sein, in diesen wenigen Sekunden kann ich dann auch auf die Weboberfläche 127.0.0.1:5080 zugreifen - aber eben nur für ein paar Sekunden.

Das installierte Capi
Code:
/usr/lib> ls -l libcapi20*
lrwxrwxrwx 1 root root    18 22. Jan 21:33 libcapi20.so -> libcapi20.so.3.0.4
lrwxrwxrwx 1 root root    19 22. Jan 21:33 libcapi20.so.2 -> libcapi20.so.2.0.10
-rwxr-xr-x 1 root root 40624 22. Feb 2011  libcapi20.so.2.0.10
lrwxrwxrwx 1 root root    18 22. Jan 21:33 libcapi20.so.3 -> libcapi20.so.3.0.4
-rwxr-xr-x 1 root root 44720 22. Feb 2011  libcapi20.so.3.0.4
scheint in Ordnung zu sein, auch capiinfo zeigt nichts Auffälliges
Code:
capiinfo
Number of Controllers : 1
Controller 1:
Manufacturer: AVM GmbH
CAPI Version: 2.0
Manufacturer Version: 3.11-07  (49.23)
Serial Number: 1000001
BChannels: 2
Global Options: 0x00000039
   internal controller supported
   DTMF supported
   Supplementary Services supported
   channel allocation supported (leased lines)
B1 protocols support: 0x4000011f
   64 kbit/s with HDLC framing
   64 kbit/s bit-transparent operation
   V.110 asynconous operation with start/stop byte framing
   V.110 synconous operation with HDLC framing
   T.30 modem for fax group 3
   Modem asyncronous operation with start/stop byte framing
B2 protocols support: 0x00000b1b
   ISO 7776 (X.75 SLP)
   Transparent
   LAPD with Q.921 for D channel X.25 (SAPI 16)
   T.30 for fax group 3
   ISO 7776 (X.75 SLP) with V.42bis compression
   V.120 asyncronous mode
   V.120 bit-transparent mode
B3 protocols support: 0x800000bf
   Transparent
   T.90NL, T.70NL, T.90
   ISO 8208 (X.25 DTE-DTE)
   X.25 DCE
   T.30 for fax group 3
   T.30 for fax group 3 with extensions
   Modem

  0100
  0200
  39000000
  1f010040
  1b0b0000
  bf000080
  00000000 00000000 00000000 00000000 00000000 00000000
  01000001 00020000 00000000 00000000 00000000

Supplementary services support: 0x000003ff
   Hold / Retrieve
   Terminal Portability
   ECT
   3PTY
   Call Forwarding
   Call Deflection
   MCID
   CCBS

Ich würde gerne versuchsweise ein älteres libcapi installieren, aber weiß nicht, woher bekommen. Hat jd. vielleicht doch noch eine Idee ?

Gruß
Z.
 
OP
Z

Znarf

Member
Geht nicht, ab 12.1 wirds mit capi und isdn unter opensuse noch gruseliger, dafür wäre ein Schritt zurück (opensuse 10.3 und 10.2 waren perfekt) der bessere Vorschlag.
Z.
 

chk

Newbie
Durch ähnliche Probleme bin ich auf diesen Thread hier gestoßen.

Hier läuft nun, nach einigem gebastel der TK-Suite-Server auf OpenSuSE/64 13.1 über eine alte Fritz PCI mit AGFEO-Anlage.

Mein Problem war das, was hier eigentlich erstmal nicht die Sorgen bereitete:
Znarf schrieb:
CAPI ISDN funktionierte noch nie

Interessanterweise wäre es so, wie es bei mir (nicht) ging, für dich, Znarf, wohl ausreichend gewesen. Deinen Fehler...
Znarf schrieb:
Offensichtlich stürzt das Programm tksock kurz nach dem Laden ab
... hatte ich Anfangs nicht und zwar weil das, was den Fehler verursacht bei mir garnicht richtig vorhanden war. Es ist nämlich genau die CAPI-Unterstützung, die da absemmelte. Bei mir war die Datei bzw. der Symlink gar nicht da:
Code:
/usr/local/tksuite_server # /etc/init.d/tksuitectl configtest
TK-Suite-Server (c) 2007 AGFEO GmbH & Co. KG Version 3.3.20
This product uses parts of the SFL package
Copyright (c) 1996-2000 iMatix Corporation
1991-2000 iMatix Corporation <http://www.imatix.com>.
This product uses parts of the SMT Kernel
Copyright (c) 1991-2000 iMatix Corporation
This program uses SQLite <http://www.sqlite.org/copyright.html>
This program uses technology developed by saltation <http://www.saltation.de>
libcapi20.so.2: cannot open shared object file: No such file or directory
Auch ein normaler Start verlief scheinbar Fehlerfrei:
Code:
/ # /etc/init.d/tksuitectl start
/etc/init.d/tksuitectl start: starting tksock...
/etc/init.d/tksuitectl start: tksock started
Und: Man konnte sich anmelden und wahrscheinlich hätte auch alles funktioniert, eben bis auf die CAPI-Unterstützung.

An dieser Stelle möchte erst nochmal auf das erste erwähnte Zitat eingehen, das es mit CAPI gar nicht klappt. Bereits länger her machte ich die Erfahrung, dass die tolle ISDN-Unterstützung die SuSE einst hatte irgendwann still und heimlich weg war. Auch AVM stellte wohl jegliche Aktivitäten in dieser Richtung ein. Ich stand damals, als ich von SuSE 7.0 auf OpenSuse (glaube 11 oder 12) umgestiegen bin, kurz davor meine gute alte Fritz!-PCI auszumustern um ihr dann ewig nachzutrauern.
Dann aber stieß ich auf die Seiten:
http://www.fkn-systems.de/index.php?&c=fcpci und
http://www.belug.de/hilfe-howtos-fcpci.html

Plötzlich ging die Sonne auf! Nein, es klappte nicht alles auf Anhieb. Den Hinweis "Externe 0 voranstellen" hatte ich fkn gegeben - war eine Leidvolle Erfahrung, die ich machen musste. Aber irgendwann klappte dann alles wie einst. Und auch heute, nach verschiedenen Updates und Upgrades: Wenn das mit dem ISDN nicht mehr klappt, schlage ich bei fkn nach und freue mich jedesmal auf's Neue.

Lange Rede, kurzer Sinn: Die Grundvoraussetzungen für die CAPI-Ansteuerung sind so erstmal gegeben. Ich wollte das kurz erwähnen, da es sicher dem ein oder anderen hilft, der hier aufschlägt.

Konkret wieder zum hier vorliegenden Problem: Als ich erkannte, dass die libcapi20.so.2 fehlt, habe ich zuerst einen Symlink erstellt. Habe da auf verschiedenstes Verlinkt, ohne wirklich zu wissen, was ich tue. Vorallem hatte ich anfangs nicht all diese Pakete installiert:



Nur das 64-bittige "-3" war da. Das, so dachte ich dann, wird mein Problem sein.
Leider war das aber nur die halbe Lösung. Ich war dann genau bei der Meldung, die mich hierher führte:

Code:
/usr/local/tksuite_server # /etc/init.d/tksuitectl configtest
TK-Suite-Server (c) 2007 AGFEO GmbH & Co. KG Version 3.3.20
...
tkmedia: symbol lookup error: /usr/lib/capi/lib_capi_mod_std.so: undefined symbol: get_buffer
shutting down...
Irgendwann kam ich dann auf eine Seite, die das "get_buffer"-Problem von anderer Richtung betrachtete. Da wurde berichtet, dass eine ältere libcapi20.s0.2 helfen könnte. In besagtem Fall half dann tatsächlich den Link auf die libcapi20.so.2.0.6 zu legen.
Die Beiträge waren aber auch schon ein paar Jahre alt und ich hatte da meine Bedenken. Und wohler bekomme ich die alte Version überhaupt. Und klappt das dann mit dem Rest...
Wie gut, dasss ich meinen alten SuSE 7-Server noch in virtualisierter Form hatte. Darin war doch, welch Glückes Geschick, u.a. tatsächlich genau diese Version.
Und was soll ich sagen: Damit klappt es nun!!!

Nun ist mein Beitrag doch länger geworden. Ich hoffe, ich habe nichts vergessen, wenn doch bitte nachfragen.
 
OP
Z

Znarf

Member
Hallo chk und alle anderen

hatte das Problem schon zur Seite gelegt (Agfeo Anlage läuft jetzt auf einem alten Rechner mit opensuse 11.2 als Fax- und Telefonanalgenserver (sonst nix), soweit in Ordnung), wäre aber schon noch an einer Lösung interessiert (dann könnte der Zusatzrechner wieder weg).

Ich kann die Fehlerbehebung nur leider partiell nachvollziehen, dafür verstehe ich von der Materie als praktisch nur Anwender viel zu wenig.

Trotzdem die Nachfrage:
Im Augenblick ist unter /usr/lib meine libcapi20.so mit libcapi20.so.3.0.4 verlinkt; libcapi20.so.2 ist mit libcapi20.so.2.0.10 verknüpft. Würde es sinnvoll sein, wenn ich libcapi20.so ebenfalls mit libcapi20.so.2.0.10 verknüpfe ??

Betr. libcapi20.so.2.0.6: Darüber bin ich meiner Erinnerung nach auch schon gestolpert (dass es damit funktioniert)...allein: Wo soll ich die herkriegen ??

Viele Grüße Z.
 
OP
Z

Znarf

Member
...jetzt ist mir noch etwas aufgefallen bei meiner Konfiguration: Von der capi library (64bit) sind zwei Pakete aus unterschiedlichen Paketquellen installiert, einmal vom offiziellen opensuse Repository capi4linux 2010.11.8-2.4
und einmal aus dem obs (kkeil) capi20 1:3.23-100.1; hier werden unterschiedliche Versionen der libcapi2* bzw. libcapi3* zur Verfügung gestellt...allerdings: nachinstalliert hab ich bewusst nie etwas, und früher lief es über Jahre :???:

nun denn Gruß Z.
 

chk

Newbie
Hi Znarf,

nun, ich habe da auch nur "gefährliches Halbwissen". :)

Wegen der verschiedenen Paketquellen würde ich mir erstmal keine Gedanken machen. Ich war auch verwirrt (siehe Screenshot von den installierten Capi-Versionen). Hier im Speziellen geht es eh nur um die 32bit-Variante, denn er sucht in /lib/ und nicht in /lib64/.

Wenn Du jetzt nur Deinen beschriebenen Fall zum laufen bringen möchtest, und die 32-Bit-Capi sonst nicht brauchst, sollte es gehen, dass Du den Symlink einfach löscht und es so keine /lib/libcapi20.so.2 mehr gibt. Wenn keine Da ist, gibt es auch keinen Fehler.
So war das bei mir ganz am Anfang, da hatte ich nur die libcapi20-3 als 64-Bit Version installiert. War völlig ausreichend für läuft meinen FAX-Server und den Anrufbeantworter.
Und auch Tk Suite lief problemlos, bis ich gerne meine Anlage via ISDN auslesen wollte...

Seriell wäre da bestimmt gegangen. Wenn Du aber nun auch gerne via Capi/ISDN auslesen möchtest, kann ich Dir die Datei gerne geben. Ist ja OpenSource (bitte korrigieren, wenn ich da irre). Kann man hier was anhängen? Oder gibt's hier einen Filebereich?

Achso, Deine Frage: Nein, mit der .10 würde ich nicht verlinken, da hat es bei mir nicht mit geklappt. Ob die .6 die letzte ist mit der es klappt kann ich nicht sagen. Was läuft denn bei Dir auf der 11'er Suse? Da funzt es doch?

vg
chk
 
OP
Z

Znarf

Member
..Hmmm?
Auf der opensuse 11.2 (wo es funktioniert) habe ich offensichtlich die identische Einrichtung
Code:
libcapi20.so -> libcapi20.so.3.0.4
libcapi20.so.2 -> libcapi20.so.2.0.10
libcapi20.so.2.0.10
libcapi20.so.3 -> libcapi20.so.3.0.4
libcapi20.so.3.0.4
Wie gesagt, hier funktioniert die Agfeo-Software bestens.

Allerdings ...und das ist der Unterschied, finden sich hier die Pakete nur unter /usr/lib64 (unter /usr/lib gibt es keine libcapi-Dateien)...

Könnte das ein Ansatz sein, dann würde ich die libcapi's unter /usr/lib einfach mal "probehalber "verschieben" ??? Am funktionierenden System ist das capi4linux-32bit nicht installiert.

Sehr komisch.

P.S. Unter
gibts bei mir keine dieser Dateien und Verknüpfungen

Gruß Znarf
 

chk

Newbie
Sehr seltsam...

Dann wäre meine Theorie ja falsch, dass bei Nichtvorhandensein von /usr/lib/libcapi20.so.2 der Fehler mangels Datei übersprungen wird. :-(

Die /usr/lib64-Versionen würde ich auf keinen Fall nach /usr/lib spielen. Denn sonst versucht 32bit Software etwas mit 64bit-Bibliotheken zu machen... das wird schief gehen, denke ich.
Obwohl ich, so glaube ich, auch mal einen Symlink probiert habe.
Momentan schaut es bei mir so aus:

Code:
 # ls -l /usr/lib/libcapi20*
lrwxrwxrwx 1 root root    18 20. Feb 11:56 /usr/lib/libcapi20.so.2 -> libcapi20.so.2.0.6
-rwxr-xr-x 1 root root 42572  7. Dez 18:36 /usr/lib/libcapi20.so.2.0.10
-rwxr--r-- 1 root root 77333 19. Feb 18:57 /usr/lib/libcapi20.so.2.0.6
lrwxrwxrwx 1 root root    18 18. Feb 19:22 /usr/lib/libcapi20.so.3 -> libcapi20.so.3.0.4
-rwxr-xr-x 1 root root 42572  7. Dez 18:36 /usr/lib/libcapi20.so.3.0.4

 # ls -l /usr/lib64/libcapi20*
lrwxrwxrwx 1 root root    18 17. Feb 20:05 /usr/lib64/libcapi20.so -> libcapi20.so.3.0.4
lrwxrwxrwx 1 root root    19 19. Feb 18:53 /usr/lib64/libcapi20.so.2 -> libcapi20.so.2.0.10
-rwxr-xr-x 1 root root 47552  7. Dez 18:25 /usr/lib64/libcapi20.so.2.0.10
lrwxrwxrwx 1 root root    18 14. Dez 19:49 /usr/lib64/libcapi20.so.3 -> libcapi20.so.3.0.4
-rwxr-xr-x 1 root root 47552  7. Dez 18:25 /usr/lib64/libcapi20.so.3.0.4

Wie gesagt: Anfangs hatte ich auch nur das 64-Bit-Paket installiert... Vielleicht liegt es auch daran, dass die Fehlermeldung ja aud der Datei kommt, die unter /usr/lib/capi liegt...

Habe gerade nochmal getestet. Wenn ich die libcapi20.so.2 lösche (also den Link), und dann aus dem tksuite-Verzeichnis mit dem Parameter "configtest" starte erhalte ich wie folgt:

Code:
:/usr/local/tksuite_server # /etc/init.d/tksuitectl configtest
TK-Suite-Server (c) 2007 AGFEO GmbH & Co. KG Version 3.3.20
This product uses parts of the SFL package
Copyright (c) 1996-2000 iMatix Corporation
1991-2000 iMatix Corporation <http://www.imatix.com>.
This product uses parts of the SMT Kernel
Copyright (c) 1991-2000 iMatix Corporation
This program uses SQLite <http://www.sqlite.org/copyright.html>
This program uses technology developed by saltation <http://www.saltation.de>
libcapi20.so.2: cannot open shared object file: No such file or directory

UND: Der Server läuft. Ich kann darauf zugreifen, mich anmelden, etc. Alles nur eben nichts, was eine Verbindung zur Anlage benötigte...


Wenn bei Dir unter /usr/lib (nicht /lib !!!) nichts liegt, dann hast Du das 32bit Paket nicht installiert? (vgl. meine Screenshos-Schnippsel von oben)

Was siehst Du denn, wenn Du yast aufmachst, Software -> Suche nach "libcapi" ?
 
OP
Z

Znarf

Member
Nein, ich glaube eigentlich, dass deine Theorie stimmt
Dann wäre meine Theorie ja falsch, dass bei Nichtvorhandensein von /usr/lib/libcapi20.so.2 der Fehler mangels Datei übersprungen wird.
, weil bei mir auf dem opensuse 11.2 (64bit) mit funktionierendem Tk-Server ja gerade die /usr/lib/libcapi20.so.2 NICHT vorhanden ist, ich hier aber die Agfeo-Software im Browser laufen habe bzw. via serieller Schnittstelle die Anlage einwandfrei konfigurieren kann.

Auf dem nichtfunktionierenden System sind die 32-bit-Bibliotheken installiert. Leider gelingt mir das Hochladen eines passenden Screenshots aus dem YAST gerade nicht, aber hier sind capi4linux, capi4linux-32bit und capi20 (ebenfalls 64bittige Bibliothek aus dem OBS mit nicht ganz identischen Dateien wie capi4linux - statt 2.0.10 ist hier 2.0.12 und statt 3.0.4 ist 3.0.6 gelistet) installiert. Die Installation liegt aber schon 5 Jahre zurück, und 4 1/2 davon liefs ja fehlerfrei :???: :???:

Trotzdem, ich kann die 32-bit Dateien ja mal aus /usr/lib rausschmeißen und schauen was passiert.

P.S. Faxempfang und -versand über die AVM Karte funktionieren übrigens auf dem System, auf dem tksuite abstürzt, ebenfalls.

Gruß Z.
 

chk

Newbie
Aber am besten ist es, wenn Du die nicht einfach so löscht, sondern die entsprechenden Pakete via yast deinstallierst.

Zwecks der Paketübersicht muss man keinen Screenshot machen. Es geht auch über die Kommandozeile:

Code:
 # rpm -qa | grep capi
libcapi20-2-2011.8.29-17.3.1.x86_64
libcapi20-2-32bit-2011.8.29-17.3.1.x86_64
libcapi20-3-2011.8.29-17.3.1.x86_64
capi4linux-2011.8.29-17.3.1.x86_64
capi4linux-32bit-2011.8.29-17.3.1.x86_64
libcapi20-3-32bit-2011.8.29-17.3.1.x86_64
capisuite-0.4.5-263.1.2.x86_64

Zu Deiner Frage, warum es nach 4½ Jahren plötzlich nicht mehr funktionierte kann ich nur die banalen Worte sagen: Da hat sich was verändert! Ja, ist mir schon klar, dass Du nichts bewusst gemacht hast. Also könnte ein automatisches Update passiert sein. Du hast da die 11.4 am laufen, richtig?
Wenn ich hier nachsehe: https://de.wikipedia.org/wiki/OpenSUSE#openSUSE_.28ab_Version_10.2.29 endete der Support der 11.4 bereits Juli 2014, Du berichtetest aber erst im Februar 2015 von Problemen. Einzige Möglichkeit, die ich mir vorstellen könnte ist, dass die Datei zwar schon 2014 draufkam, aber bis 2015 die TK-Suite (oder der ganze Rechner) nicht neu gestartet wurde.
Kann da was dran sein? Man kann das vielleicht noch feststellen, wenn man sich mit yast die Vor-Versionen des Pakets ansieht.
 

Sauerland

Ultimate Guru
openSUSE 11.4 war bis vor kurzem Evergreen und wird teilweise sogar jetzt noch mit Patches versorgt, z.B. der letzte glibc Patch wurde in Evergreen 11.4 eingepflegt.

Dafür musste man aber explizit auf das Evergreen Repo umstellen.

Ist bei 13.1 nicht mehr nötig, das läuft automatisch über das Upsdate >Repo.
 
OP
Z

Znarf

Member
ad chk...sorry, da hätt ich selber auch draufkommen können
Code:
rpm -qa | grep capi
capi20-3.23-100.1.x86_64
capi4linux-2010.11.8-2.4.x86_64
capisuite-0.4.5-249.3.x86_64
capi4linux-32bit-2010.11.8-2.4.x86_64

und ja, sauerland hat recht, ich habe das Evergreen Repo eingebunden und sicherlich 2015 auch noch immer mal wieder irgendwelche Pakete nachinstalliert oder geupdated. Der Rechner wird jeden Tag benutzt, meist sehr intensiv.
Also dann werde ich die ...-32bit Variante mal deinstallieren (muss aber vorher schauen, obs die im Repo für alle Fälle noch gäbe).
Danach werde ich die tksuite-Software nochmals neu einspielen und schauen was passiert, kann allerdings etwas dauern, weil ich im Augenblick beruflich sehr absorbiert bin...Aber gut Ding hat Weile, wie man an diesem Thread sieht


Gruß Z.
 
Oben