Hallo zurück
Am Di 06.02.2007 21:34 schrieb Claudius Euteneuer
Na, wenn das so ist, dann schmeißen wir doch gleich noch die anderen Pakete von der Wishlist in den Build Service... ;-) Von der Wishlist: tuxmath => ready TkGate => muss noch gefixt werden. Die kenne ich noch nicht. Bin aber schon gespannt...
Vorsicht: tuxmath hat Suchtpotential! ;-)
xfig => ready (schon in der Distri) italc => ready, aber noch nicht getestet:
http://software.opensuse.org/download/home:/lrupp/openSUSE_10.2/i586/ wow, hier geht's ja richtig rund!
Nun - hier muss man unterscheiden: - Einen "tarball" in ein .deb oder rpm packen ist relativ einfach. (und genau das mache ich gerade... ;-) - Sich den Quellcode genauer zu Gemüte führen und "verstehen", was der/die Programmierer da gemacht haben ist dann die hohe Schule des Packaging. ...und eine "Policy" bei Suse besagt, dass nur solcherart "reviewte" Pakete Eingang in die (Enterprise-)Distribution finden. Ähnlich ist das übrigens auch bei anderen Distributionen. Aufgabe des Packagers ist es dann u.a. auch Fehler in der Software zu suchen und an "upstream" (also den eigentlichen Autor) zu melden - am besten gleich mit einem passenden "Patch", der das Problem beseitigt...
BTW: jmd. hier, der "Packagen" kann/ lernen möchte? Hier! (Also: kann nein - lernen ja)
Kein Problem - wir sind ja auf der Edu-Liste ;-) Sollte sich jmd. dadurch gestört fühlen, wenn wir das hier auf dieser Liste machen, dann kann er sich ja melden. Ansonsten würde ich sagen: nehmen wir uns ein Paket von der Wishlist und fangen damit an... ...ich versuche mal weiter unten schon mal ein wenig in die Thematik einzusteigen. Man möge mir dies verzeihen ;-)
Hier schon mal eine Frage: Einer der Gründe, nein, eigentlich sogar _der_ Grund, warum ein Schüler es mal geschafft hat mich von SuSE nach Debian zu überreden ist der, dass bei Debian benötigte Abhängigkeiten automatisch aufgelöst werden. Geht das mit RPM auch?
*lach* Natürlich geht das auch mit RPM. Das ist ja u.a. auch eine der Hauptaufgaben bei einem Paketmanager. Es ist aber _auch_ Aufgabe eines Paketmaintainers (Packagers), diese Abhängigkeiten "einzupflegen". RPM verfügt einerseits schon einen "Automatismus", welcher sog. "Requires" (das Paket bietet z.B. Bibliotheken an) und "Provides" (das Paket benötigt bestimmte Bibliotheken) schon bei der Generierung des Pakets einbaut. Beispiel: die Ausgaben von "rpm -qp --provides apache2" oder rpm -qp --requires apache2" listen auf, was das apache2-Paket alles "anbietet" und was es andererseits "braucht". Der Paketmanager (in diesem Fall RPM) hat diese (und andere) Daten in seiner Paketdatenbank, die auf jedem System existiert und kann dann z.B. warnen, wenn man ein Paket deinstallieren will, welches noch von anderen Paketen benötigte Sachen enthält. Andere Sachen kann der Paketmanager (RPM) nicht automatisch beim Bau eines Pakets ermitteln (weil er sie z.B. beim . Wenn etwa ein Paket wie "moodle" sinnvollerweise nur zusammen mit einem Webserver sinn macht, dann muss diese Abhängigkeit der Paketmaintainer beim Bau des Pakets eintragen. ...und da kommt dann wiederum die "Qualität" des Paketmaintainers ins Spiel, der diese zusätzlichen Abhängigkeiten erkennen und eintragen muss.
[klogic] ... na gut, Gleischungseditor liest sich etwas komisch ;-) Ich schreib ihm mal.
Eben: das sind eigentlich recht simple Sachen, die man mit jeder Schulklasse die Deutsch und Englisch kann, machen kann: "Übersetzt diesen Text vom Englischen ins Deutsche - aber achtet auf den Kontext, in welchem dieser Text angezeigt wird...." ...und als "Belohnung" wird Euer Name als Übersetzer später in diesem Programm erwähnt werden, welches weltweit eingesetzt wird. 8-)
Bei mir ist das übrigens: /usr/share/locale/de/LC_messages/klogic.mo (Debian halt...) Wie bearbeitet man so eine Datei? Selbst emacs ist überfordert. :-(
Nein - eine solche Datei bearbeitet man weder bei Debian noch bei SUSE noch bei einer anderen Distribution. Hier bist du "zu spät" eingestiegen: du hast das "Binary" (also das fertig in Computersprache übersetzte Programm) genommen und nicht den Sourcecode. Das hab ich evtl.falsch geschrieben. Was du brauchst, ist diese Datei hier: http://www.a-rostin.de/klogic/Version/klogic-1.63.tar.gz => Das sind die sog. "Sourcen". Wenn du die (z.B. mit dem Befehl "tar -xvzf klogic-1.63.tar.gz") auspackst, erhälst du ein neues Verzeichnis. Dort drin gibt es ein Unterverzeichnis namens "po" und in diesem wiederum eine Datei namens "de.po". Diese de.po wird später vom Compiler in Maschinensprache (deine klogic.mo-Datei) übersetzt. ...und jetzt kommen wir zu einem ersten Packaging-Beispiel: http://software.opensuse.org/download/Education:/desktop/openSUSE_10.2/src/k... Dies ist die "Source-Datei" mit allen Sachen, die _ich_ als Packager zusätzlich "verbrochen" habe, um das Programm auf openSUSE zum Laufen zu bringen. Wenn du dir diese Datei herunterlädst, kannst du sie dir unter Debian z.B. mit dem MidnightCommander anschauen: Datei markieren und [Enter] drücken: /INFO => Hier stehen generelle Informationen zum Paket. Z.B auch, auf welchem Rechner es wann gebaut wurde. CONTENTS.cpio => ein RPM ist nichts weiter als ein "erweitertes" cpio-Archiv. Du kannst mit dem MC auch dieses Archiv "auspacken": => klogic-1.63.tar.bz2 => der Source-Tarball, so wie er zum Download bereit steht. Ich habe ihn nur (um Platz zu sparen) mit einem besseren Packprogramm "umgepackt". => klogic-configure.in.in.patch => der Autor hat in seinem Code dafür gesorgt, das die *.po-Dateien in einer chroot-Umgebung mit dem Namen "tmp.mo" erzeugt werden. Ich sorge mit diesem "Patch" dafür, dass die erwarteten "klogic.mo" Dateien erzeugt werden. Der "Patch" sieht hierbei so aus: --------------------------------------------[schnipp] --- configure.in.in.org 2007-02-05 14:31:01.000000000 +0100 +++ configure.in.in 2007-02-05 14:31:11.000000000 +0100 @@ -1,6 +1,6 @@ #MIN_CONFIG(3.0.0) -AM_INIT_AUTOMAKE(tmp, 0.1) +AM_INIT_AUTOMAKE(klogic, 0.1) AC_C_BIGENDIAN AC_CHECK_KDEMAXPATHLEN --------------------------------------------[schnapp] => Oben steht, welche Dateien "betroffen" sind: configure.in.in.org ist die Originaldatei (diese wird später "gepatched"), configure.in.in meine angepasste Datei. Die Zeile mit dem "-" wird aus dem original-Code entfernt, die Zeile mit dem "+" wird hinzugefügt. Die anderen Zeilen bleiben erhalten und dienen nur der Orientierung. Ich gebe zu: kein großer Patch - aber er funktioniert erst mal ;-) Meine Aufgabe als Packager ist es nun, diesen Patch dem original Autor zukommen zu lassen, damit er ihn sich anschauen kann. Ist er damit einverstanden, nimmt er ihn in den Sourcecode auf und ich erspare mir in der nächsten Version die Arbeit, diesen Patch evtl. anzupassen. Nimmt er ihn (aus welchen Gründen auch immer) nicht auf, dann mache ich damit mein Paket zu einem "da machen die SUSE Leute wieder irgendetwas komisches"-Paket weil ich ohne diesen Patch in einer chroot-Umgebung ohne root-Rechte das Programm nicht sauber kompiliert kriege. => klogic-german-language.patch => Diese Patch korrigiert einige Übersetzungen in der de.po Datei. Er ist zu lang um ihn hier in die Mail zu posten. Wer möchte, kann ihn ja im Source-RPM anschauen. (Aber dies ist z.B. ein Anfang bei der Anpassung der Übersetzung.) Wichtig: ein Paketmaintainer sollte nie den Original-Sourcecode ändern und diesen danach packagen! Warum? Nun, dies hat mehrere Gründe: a) Weiß er selbst im allgemeinen nach kurzer Zeit nicht mehr genau, was er da warum geändert hat. b) Ist es dem Originalautor gegenüber unfair (Schließlich bekommt der ggf. Fehlermeldungen von Benutzern, die die veränderte Version benutzen und kann nicht nachvollziehen, _warum_ diese Fehler bei den Benutzern auftauchen. c) Ist es anderen Packagern oder Benutzern gegenüber unfair, die evtl. mal nachsehen möchten, was "die SUSE" da nun wieder am Paket verändert hat. d)... (durch beliebige Argumente zu erweitern) Deshalb: Ja, man muss manchen Sourcecode ändern - aber man sollte, wenn man ein Paket daraus erstellen möchte, diese Änderungen Dokumentieren. Dies geschieht im technischen Sinne durch solche Patches, die gegen den original Sourcecode erstellt werden. Im obigen Beispiel weiß ich als Packager z.B. auch in drei Jahren noch, welche Datei und welche Änderungen in dieser Datei ich damals vorgenommen habe, um das Programm zum Laufen zu bekommen. => klogic.spec => Dies ist die "Steuerdatei" zum Erstellen eines RPMs. Jeder, der schon einmal auf der "Bash" unterwegs war, dürfte sich da schnell heimisch fühlen. Jeder, der schon einmal einen oben erwähnten "Source-Tarball" kompiliert hat, ebenfalls. Die Spec-Datei listet einerseits die erzeugten und benötigten Dateien auf, andererseits werden hier auch die "./configure; make; make install;"-Aufrufe gemacht. Dadurch, dass diese Datei bei einem Source-RPM dabei ist, sollte man z.B. auch nach Jahren noch genau wissen, mit welchen Optionen ein Programm kompiliert worden ist. Debian verfolgt hier einen etwas anderen Ansatz und packt diese Sachen in einen speziellen Ordner. Aber auch hier dient das dazu, die gemachten Aufrufe und Patches für die Nachwelt und interessierte Programmierer zu erhalten. So - ich denke, das reicht für den Anfang. ;-)
Sollen da auch Programme rein, die eigentlich schon in SuSE drin sind, damit man sieht, was man mit Linux alles machen kann?
Jain. Ich würde diese _EDU_Wishlist gerne mit Programmen gefüllt sehen, die wirklich einen eher pädagogischen Hintergrund haben. OpenOffice z.B. dürfte im Unterricht genauso Verwendung finden wie ein Firefox oder Opera. Aber direkt auf den Edu-Bereich ausgerichtet sind diese Programme weniger. Spezielle Vorlagen für OpenOffice oder Schulungsunterlagen für Firefox wären da in meinen Augen schon eher etwas für die Liste. Aber das ist meine Meinung - es gibt da sicherlich auch andere Ansichten.
(Kate, Quanta, kile, emacs, xpdf, kmplot, inkscape, scribus, gimp, gqview, amarok, ripperX (?), krecord (wegen der Fourieranalyse ;-) ), k3b, thunderbird, lightning, firefox, realplayer, flashplayer, xarc, xarchiver, OpenOffice.org, xaos, kino, cinelerra, ...)
Vorschlag: Eine zweite Wiki-Seite, die die Programme auflistet, die später einmal auf einen EDU-Rechner kommen sollen. Die könnte dann z.B. auf Anleitungen oder gar Unterrichtsbeispiele zu einzelnen Programmen verlinken. Ich hab jetzt mal eine englische Seite angefangen: http://en.opensuse.org/Education_Programs die können wir später ja noch übersetzen.
Lazarus, freePascal, gambas
=> Ab auf die Wishlist :-)
Seit 29.12.07 Vogdt, vorher Rupp ;-) Klingt nach Gratulieren!? Herzlichen Glückwunsch ;-)
Danke. Grüße zurück, Lars *derheutAbendseinenaltenNamennimmt* -- To unsubscribe, e-mail: opensuse-edu-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-edu-de+help@opensuse.org