[gelöst] Kann Verbindungen mit KNetAttach nicht löschen

Hallo,

nachdem die Installation von FileZilla auf OpenSuse 21.1 bei mir gescheitert ist, weil die RPM Pakete nicht richtig aufgelöst werden habe ich mit mit KNetAttach beschäftigt.

Jetzt habe ich einen Eintrag den ich gerne wieder los werden möchte.
Wenn ich versuche diesen Eintrag in Dolphin --> Netzwerk --> linke Maustaste zu löschen erhalte ich die Meldung:
Kann man das an einer anderen Stelle löschen? In welchem Konfig-File könnte ich das notfalls manuell rausschmeissen?

Gruß
Georg

Das müsste in deiner Konfig (in deinem /home von Netattach bzw. Dolphin zu finden sein

Etwas OT, aber trotzdem: Wieso hattest du denn Probleme bei der Installation von Filezilla? Das ist doch im OSS-Repo:

Hallo,

Yast hat die libtinyxml in keinem Repository gefunden, und ich habe alle üblichen Verdächtigen eingebunden.
Dann habe ich mir eine 64 bit und ein 32 bit Version der http://software.opensuse.org/121/de heruntergeladen und installiert.
Das Ergebnis sieht so aus, in beiden Versionen.

Gruß
Georg

Hallo,

ich habe festgestellt, dass das Löschen von KNetAttach Verbindungen in Dolphin nur im Kontextmenü der rechten Maustaste scheitert.
Aber es funktioniert, wenn man die Verbindung markiert und dann die Löschtaste drückt.

Die Einträge befinden sich übrigens im Verzeichnis ~/.kde4/share/apps/remoteview
Die Passworte in kwallet, an das komme ich allerdings zur Zeit nicht dran siehe http://www.linux-club.de/viewtopic.php?f=24&t=115396.

Gruß
Georg

Mal abgesehn davon benötigt dein Filezilla 32 Bit Bibliotheken

Hallo spoensche,

Du hast Recht. Ich habe die 32Bit Version von libtinyxml installiert und Filezilla kommt ein Stück weiter. Jetzt verlangt Filezilla aber die nächste Library, wohl auch in 32Bit. Und das Paket verlangt die Installation weiterer 32Bit Pakete.

Ich wusste gar nicht, dass es solche Kombinationen gibt. Schieße ich mir nicht ins Knie, wenn ich ein 32/64 Bit Mischsystem aufbaue? Ich befürchte, dass dann andere Programme abschmieren, wenn ich Libraries ersetze.

Gruß
Georg

Auf einem 64 Bit-System installiert man 32 Bit-Programme nur dann, wenn diese nicht als 64 Bit-Versionen zur Verfügung stehen (filezilla z. B. gibt es auch als 64 Bit-Paket im oss-Repo). Pakete mit dafür notwendigen Bibliotheken haben "-32bit" im Paketnamen (Architektur=x86_64). "Normale" 32 Bit-Bibliotheken (Architektur=i586) haben auf einem 64 Bit-System nichts verloren.

Für mich ist eine Meldung wie

P6CNAT schrieb:

filezilla: error while loading shared libraries: libtinyxml.so.0: wrong ELF class: ELFCLASS64

Zum Vergrößern anklicken....

einer von vielen Bausteinen für Deine Probleme.

Hallo josef-wien,

du hast Recht. Filezilla war tatsächlich in einer 32Bit Version installiert ps:
Es ist mir schleierhaft, wie das passieren konnte, ich habe das Paket mit Yast installiert, da kann man doch gar keine 32Bit Version auswählen :???:

Ich habe Filezilla und libtinyxml deinstalliert. Bis auf den master-boot-code-1.22-7.1.2.i586 waren es die einzigen 32Bit Pakete auf meinem System. Ich vermute aber, dass der master-boot-code in 32Bit gebraucht wird.

Ich habe noch ein grundsätzliches Problem mit dem Repository 'openSUSE-12.1-Oss'. Deshalb kann ich wohl auch keine Pakete installieren, weil die Abhängkeiten nicht aufgelöst werden können. Ich habe mich einem anderen Thread angeschlossen, damit es hier nicht so strubbelig wird. Siehe http://www.linux-club.de/viewtopic.php?f=62&t=115407&p=725924#p725924

Gruß
Georg

P6CNAT schrieb:

ich habe das Paket mit Yast installiert, da kann man doch gar keine 32Bit Version auswählen

Zum Vergrößern anklicken....

Rechts unten im Reiter "Versionen" ist auch das möglich.

P6CNAT schrieb:

Ich vermute aber, dass der master-boot-code in 32Bit gebraucht wird.

Zum Vergrößern anklicken....

Im Paket master-boot-code steckt auch das Programm fixmbr, das nichts anderes macht, als einen generischen Boot-Code in den MBR zu schreiben (der eine aktive Partition sucht und deren Boot-Code ausführt). Da ist es verständlich, daß sich niemand der Mühe unterzieht, eine 64 Bit-Version davon zu erzeugen. Ich ziehe für solche Fälle aber nach wie vor den Befehl dd vor (aber jetzt sind wir vom Thema schon meilenweit entfernt).