ubuntuusers.de

Die Fehlermeldung ist irreführend. Vermutlich fehlt das Paket libgtk2.0-dev.

Lösung: sudo apt-get install libgtk2.0-dev

Gruß - Max-Ulrich

Hallo,

vielen Dank...!

Genau das fehlte.

Nun habe ich den Rest so gemacht wie du das beschrieben hast.

Bekomme aber nun diese Fehlermeldung...kann das an dem 64bit System liegen?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

mygtk.c: In Funktion »setbusycursor«:
mygtk.c:1168:3: Fehler: Zu wenige Argumente für Funktion »gtk_widget_set_visible«
/usr/include/gtk-2.0/gtk/gtkwidget.h:969:23: Anmerkung: hier deklariert
mygtk.c:1171:3: Fehler: Zu wenige Argumente für Funktion »gtk_widget_set_visible«
/usr/include/gtk-2.0/gtk/gtkwidget.h:969:23: Anmerkung: hier deklariert
make[2]: *** [xfprot-mygtk.o] Fehler 1
make[2]: Verlasse Verzeichnis '/home/stenneken/Downloads/1/xfprot-2.4/src'
make[1]: *** [all] Fehler 2
make[1]: Verlasse Verzeichnis '/home/stenneken/Downloads/1/xfprot-2.4/src'
make: *** [all-recursive] Fehler 1
stenneken@MATRICA:~/Downloads/1/xfprot-2.4$

kann das an dem 64bit System liegen?

Glaube ich nicht.

Hast Du vielleicht beim Kopieren versehentlich das Argument (widget) mit herausgekillt? Oder fehlt eine Klammer? Oder ist irgendwo ein Leerzeichen zu viel? Der Source-Abschnitt muss so lauten:

/************ Set busy cursor  ********************************/

void setbusycursor(GtkWidget *widget, int flag)
{
	GdkCursor *busyCursor = gdk_cursor_new(GDK_WATCH);
	
	if (flag == TRUE) {
		if(gtk_widget_get_visible(widget))
			gdk_window_set_cursor(widget->window, busyCursor);
	} else {
		if(gtk_widget_get_visible(widget))
			gdk_window_set_cursor(widget->window, NULL);
	}
}

Hi,

hab ´s genau so wie du.

Geht leider nicht, schade...!

Wichtige Korrektur!

In meinem obigen Post hatte ich geschrieben:

2. Ersetze in der Datei mygtk.c die Passagen GTK_WIDGET_VISIBLE durch gtk_widget_set_visible (zwei mal, ziemlich am Ende der Datei).

Dies ist leider ein Tippfehler 😳 . Es muss heißen gtk_widget_get_visible

Ich bitte um Entschuldigung!

Gruß - Max-Ulrich

Hi,

das freut mich....!

Nun läuft es dank deiner Hilfe einwandfrei....!

Vielen Dank für deine Mühe.

Gruß Jens

-hardy, ungetestet ab 09.05.13

Es sind einige Änderungen/Ergänzungen fällig. Deshalb bitte ich um eine Baustelle.

Gruß - Max-Ulrich

P.S. Gleichzeitig bitte ich auch um eine Baustelle für den Artikel BitDefender, damit beide Artikel aufeinander abgestimmt werden können.

Bitte sehr! Ggf Datum anpassen. Gruss

Folgendes ist nun der Stand der Dinge:

• Die auf der Download-Seite⮷ angebotene für 32-Bit Systeme kompilierte Version von F-PROT (nicht XFprot!) läuft bei mir auch auf einem 64-Bit-System völlig problemlos.

• Wenn man die bei der Installation angebotene Aktualisierung der Signaturen per Cronjob verwendet, ist auch die Aktualisierung kein Problem. Möchte man die Aktualisierung von Hand oder per GUI vornehmen, muss man noch ein kleines Wrapper-Skript (3 Zeilen) in /usr/local/bin anlegen.

• Das graphische Frontend XFprot wird offiziell nicht mehr gewartet. Die angebotene Version 2.4 läuft mit der aktuellen Version 6.5 von F-PROT leider nicht. Lasall hat XFprot 2.4 in dankenswerter Weise gepatcht (Version 2.4.1); von dem gepatchten Frontend liegen Debian-Pakete in 32- und 64-Bit-Versionen vor. Diese sind mit Ubuntu 12.04 LTS erstellt und laufen mit F_PROT 6.5 unter den aktuellen Ubuntu-Versionen.

• Frage: Kann ich die gepatchten Pakete hochladen und in den Wiki-Artikel einbinden (115,2 kB)? Wenn ja, wie mache ich das? Ich betreibe keinen eigenen Webserver! (siehe Wiki/Syntax (Abschnitt „Anhaenge“): "Deb-Pakete sind nicht als Anhang erlaubt!").

Gruß - Max-Ulrich

Hi Max-Ulrich,

Debian-Pakete und dynamisch gelinkte Binaries (die in fast allen Debian-Pakete sind) würde ich nicht hochladen, weil diese bei unterschiedlichen Ubuntu-Version inkompatibel sein können - dazu kommen dann noch mehrere Architekturen. Allerdings machen Debian-Quellcodearchive imho durchaus Sinn (.debian.tar.gz), die den Debian-Code inkl. Patches beinhalten. Wenn man ein nicht mehr gewartetes Programm nutzen möchte, sollte man zumindest mit Anleitung in der Lage sein, das Paket selbst zu erstellen. In der Beschreibung dann also den XFprot-Code normal von der Homepage herunterladen, dann den Debiancode dorthinein entpacken, dann bauen.

Gruss Lasall

Danke, Lasall.

Ich habe die Pakete aus den 3 Dateien erstellt, die Du hier angeboten hast, und bin genau nach Deiner Anleitung

dpkg-source -x xfprot_2.4-1.dsc   # Debianquellpaket entpacken
cd xfprot-2.4                     # in Debianquellcode wechseln
sudo mk-build-deps -ir            # Build-Abhängigkeiten installieren
dpkg-buildpackage                 # Paket bauen
sudo dpkg -i ../xfprot_2.4-1_amd64.deb  # Paket installieren  

vorgegangen. Dabei musste ich noch 2 Pakete nachinstallieren und die führenden Ziffernfolgen bei einigen Dateinamen entfernen. Das geht so ja nur, wenn man alle 3 Dateien von Dir verwendet und nicht etwa die Original-Datei von der Homepage, die wegen ihres anderen Namens ja von xfprot_2.4-1.dsc wohl gar nicht erkannt wird (?).

Das hat zwar alles problemlos geklappt, aber ich bin mit dem ganzen Vorgang doch so wenig vertraut, dass es mir wohler wäre, wenn Du den Patch samt Anleitung selbst in den Artikel einfügen könntest. Oder gibt es irgendwo in einem anderen Artikel eine "Vorlage", die man einfach mit geänderten Dateinamen kopieren könnte?

Außer dem Patch für XFprot ist ja nur noch das kleine Wrapper-Skript für fpupdate einzufügen und die Abbildung zu ersetzen, dann ist der Artikel wieder aktuell.

Gruß - Max-Ulrich

Hi Max-Ulrich,

das Vorgehen ist wie folgt (ungetestet):

1. XFprot von Homepage herunterladen: xfprot-2.4.tar.gz ⮷

2. Nach xfprot-2.4.orig.tar.gz umbenennen bzw. Symlink setzen.

3. Entpacken.

4. In entpacktes Verzeichnis wechseln.

5. xfprot_2.4-1.debian.tar.gz herunterladen und in das aktuelle (Quellarchiv-)Verzeichnis entpacken. Im entpackten Quellarchiv ist nun ein Ordner debian/.

6. Build-Abhängigkeiten installieren: sudo mk-build-deps -ir

7. Bauen: dpkg-buildpackage -us -uc

8. Installieren.

Gruss Lasall

Ich verstehe nicht ganz.

Im Wiki als Anhang angeboten wird also nur die Datei xfprot_2.4-1.debian.tar.gz (?); die Datei xfprot_2.4-1.dsc wird also nicht benötigt?

Wenn das Skript xfprot_2.4-1.dsc gar nicht angeboten und verwendet wird, wozu muss man dann nach dem Herunterladen von der Homepage den Tarball xfprot-2.4.tar.gz überhaupt umbenennen bzw. verlinken (?). Er wird ja von Hand in ein beliebiges Verzeichnis entpackt. Dorthin wird dann auch der Tarball xfprot_2.4-1.debian.tar.gz entpackt, und anschließend werden dort die Befehle sudo mk-build-deps -ir und dpkg-buildpackage -us -uc ausgeführt (wozu die Parameter -us -uc?) . Fertig und installieren.

Sehe ich das so richtig?

Gruß - Max-Ulrich

Hi Max-Ulrich,

du schriebst:

Im Wiki als Anhang angeboten wird also nur die Datei xfprot_2.4-1.debian.tar.gz (?); die Datei xfprot_2.4-1.dsc wird also nicht benötigt?

Genau.

Wenn das Skript xfprot_2.4-1.dsc gar nicht angeboten und verwendet wird, wozu muss man dann nach dem Herunterladen von der Homepage den Tarball xfprot-2.4.tar.gz überhaupt umbenennen bzw. verlinken (?). Er wird ja von Hand in ein beliebiges Verzeichnis entpackt. Dorthin wird dann auch der Tarball xfprot_2.4-1.debian.tar.gz entpackt, und anschließend werden dort die Befehle sudo mk-build-deps -ir und dpkg-buildpackage -us -uc ausgeführt (wozu die Parameter -us -uc?) . Fertig und installieren.

Umbenennen weil das Paket nicht nativ ist, sondern vom Quellpaketformat "3.0 (quilt)". Die Optionen -us und -uc werden dazu verwendet, damit sowohl die Quellkontrolldatei (.dsc) als auch die Änderungsdatei (.changes) nicht signiert werden.

Sehe ich das so richtig?

Ja.

Gruss Lasall