Hallo allerseits!
Ich habe einige Grundsatz-Fragen und einige Probleme beim Bauen einiger RPMs.
Grundsatzfragen:
1. Gibt es ein Programm, mit dem ich einigermaßen komfortabel Specfiles erstellen, vorallem aber verwalten kann? Eigene rpmmacros setzen und so nervige "Kleinigkeiten" wie korrekte Tags im Changelog. Bisher nutze ich meist fedora-newrpmspec, aber das ist ja eine eher einfach gehaltene Vorlage.
2. Ich baue Pakete für Core 3 und 4. Ich frage mit, ob es sinnvoll ist, getrennte SRPMS bereit zu stellen oder ob ich nicht SRPMS bauen soll, die auf beiden Distributionen bauen.
3. Abhängigkeiten: Ich denke, es ist sinnvoll, die Abhängigkeiten auf Core 3 oder 4 abzustimmen, man liest ja immer wieder, daß Leute einfach Pakete installieren, die Sie mittels rpmfind gefunden haben ;-) Nehmen wir an, ein Programm braucht gtk >= 2.2 zum compilern. Einerseits soll das Specfile bzw. das SRPM so allgemein gehalten sein, daß es ab gtk 2.2 läuft, das RPM soll aber Release-spezifisch gtk >= 2.8 oder 2.10 haben.
Ich könnte natürlich Requires: gtk2 >= 2.10.0 BuildRequires: gtk2-devel >= 2.10.0 machen, aber schon hier müsste ich ja für Core 3 und 4 verschiedene SRPMS haben.
4. Oder kann ich solche Sachen beim rpmbuild mittels "define ..." setzen, ohne das Specfile ändern zu müssen?
5. Automatisches Signieren vom Paketen (in Scripten, also ohne die Passphrase einzugeben?
Probleme:
1. Ich habe ein Paket, das ich nicht mit dem %setup macro entpackt bekomme. Erstmal erzeugt das Paket kein Verzeichnis, also habe ich setup -n genommen, was aber auch scheitert. Die Datei ist ein .tar.bz2, allerdings kann ich sie nicht wie gewöhnlich mit
$ gzip -dc foo.tar.bz2 | tar -xvvf -
enpacken: gzip: foo.tar.bz2: not in gzip format
mit bunzip2 -dc ... geht, aber wie sieht das als rpmmarco aus?
2. Ich habe das gaimnosd-0.7-1.4.0.src.rpm von https://sourceforge.net/project/showfiles.php?group_id=96242 gegen gaim-1.4.0 gebaut, allerdings verstehe ich was nicht: Aus dem Specfile:
%define gaim_major_ver %(echo %{gaimver} | sed -e 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/' -) %define gaim_minor_ver %(echo %{gaimver} | sed -e 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\2/' -)
^^^ Wo ist der Unterschied zwischen Major und Minor Version? Beide sed Ausdrücke liefern bei mir das gleiche zurück...
Viele Fragen, ich weiß. Danke für Antworten, Links, RTFMs etc.
Christoph
Am Sonntag, den 24.07.2005, 22:17 +0200 schrieb Christoph Wickert:
- Gibt es ein Programm, mit dem ich einigermaßen komfortabel Specfiles
erstellen, vorallem aber verwalten kann? Eigene rpmmacros setzen und so nervige "Kleinigkeiten" wie korrekte Tags im Changelog. Bisher nutze ich meist fedora-newrpmspec, aber das ist ja eine eher einfach gehaltene Vorlage.
Ich kenne da nix sinnvolles außer einem Editor und einem CVS Server.
Ich hab mir dafür ein VIM Makro gemacht:
map ^E /^.changelog/^[o^[k:r ! date '+%a %b %d %G'^MA Stefan Held obi@unixkiste.org^[I* ^[o-
Da ich mir nicht sicher bin ob der Mailinglisten Manager das nicht verhunzt, oder eventuell mein oder dein Mail Programm hab ich nochmal auf meinen Webserver gestellt:
http://unixkiste.org/changelog
und ja, die komischen Zeichen wie ^M gehören da dringend rein :-) Im VIM selbst erzeugst du die mit strg+v und strg+Buchstabe falls du das nicht eh schon weist.
Wenn ich im Kommando Mode bin drücke ich nur noch strg+e und et voilà lande ich direkt am ersten Changelog Eintrag :-)
Kommt halt immer drauf an wie oft man es braucht :-)
- Ich baue Pakete für Core 3 und 4. Ich frage mit, ob es sinnvoll ist,
getrennte SRPMS bereit zu stellen oder ob ich nicht SRPMS bauen soll, die auf beiden Distributionen bauen.
Das wäre imho zu bevorzugen.
- Abhängigkeiten: Ich denke, es ist sinnvoll, die Abhängigkeiten auf
Core 3 oder 4 abzustimmen, man liest ja immer wieder, daß Leute einfach Pakete installieren, die Sie mittels rpmfind gefunden haben ;-) Nehmen wir an, ein Programm braucht gtk >= 2.2 zum compilern. Einerseits soll das Specfile bzw. das SRPM so allgemein gehalten sein, daß es ab gtk 2.2 läuft, das RPM soll aber Release-spezifisch gtk >= 2.8 oder 2.10 haben.
Du kannst mal einen Blick werfen auf das Postfix RPM von Simon Mud => http://postfix.wl0.org/en/available-packages/
Der hat da einige Dinge dabei die sowas tun. Unter anderem auch ein sh script das ihm die abhängigkeiten im spec file korrekt setzt.
Ich könnte natürlich Requires: gtk2 >= 2.10.0 BuildRequires: gtk2-devel >= 2.10.0 machen, aber schon hier müsste ich ja für Core 3 und 4 verschiedene SRPMS haben.
Dann solltest du aber das RPM auch Version Specific labeln nach dem Build.
- Oder kann ich solche Sachen beim rpmbuild mittels "define ..."
setzen, ohne das Specfile ändern zu müssen?
Müsste auch gehen. Ich würde allerdings den User einbeziehen. Komfort ist schön und gut aber naja :-)
- Automatisches Signieren vom Paketen (in Scripten, also ohne die
Passphrase einzugeben?
Uh gute Frage, ich signieren meine Pakete im moment noch nicht, da ich Sie eh nur selbst benutze. Du solltest allerdings in /usr/share/doc/rpm oder auf rpm.org die passende Doku lesen.
Eventuell kann einer der hier mitlesenden Extras Packager ja was dazu sagen *ZuAlexschiel* :-)
Probleme:
- Ich habe ein Paket, das ich nicht mit dem %setup macro entpackt
bekomme. Erstmal erzeugt das Paket kein Verzeichnis, also habe ich setup -n genommen, was aber auch scheitert. Die Datei ist ein .tar.bz2, allerdings kann ich sie nicht wie gewöhnlich mit
$ gzip -dc foo.tar.bz2 | tar -xvvf -
enpacken: gzip: foo.tar.bz2: not in gzip format
hmm ich weis nicht was du da anstellst aber ich hab als
SOURCE0: foo.bar.tar.bz2 drin und dann entpackt mir das %setup das automatisch.
im übrigen ist das oben blödsinn, a.) tar xv'z'f entpackt tar.gz automatisch. Du musst nur auf *BSD und Solaris aufpassen weil dort das standard tar sowas nicht kann.
Für bz2 files kannst du anstatt dem z ein j einsetzen.
sed -e 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/' -) sed -e 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\2/' -)
Major Version ist die Hauptversions Nummer, die Minor dann die kleinere.
Beim aktuellen gaim also: Major 1 Minor 4.
Ehm ich würde einfach mal sagen, dieser Sed Ausdruck ist kaputt. :-) Ich kann mich aber auch täuschen.
Am Donnerstag, den 28.07.2005, 03:17 +0200 schrieb Stefan Held:
Ich hab mir dafür ein VIM Makro gemacht:
welches natürlich in die ~/.vimrc gehört.
Am Do, den 28.07.2005 schrieb Stefan Held um 3:17:
- Automatisches Signieren vom Paketen (in Scripten, also ohne die
Passphrase einzugeben?
Uh gute Frage, ich signieren meine Pakete im moment noch nicht, da ich Sie eh nur selbst benutze. Du solltest allerdings in /usr/share/doc/rpm oder auf rpm.org die passende Doku lesen.
Eventuell kann einer der hier mitlesenden Extras Packager ja was dazu sagen *ZuAlexschiel* :-)
Ich denke, ich bin gemeint. (Pass auf, dass die Augen nicht so bleiben!)
Ich hoffe, dass in Kürze "keychain" den Weg nach Fedora Extras findet. Einen 1. review Durchgang hatte es schon, nach einer besonderen Anpassung an Fedora warte ich auf nochmaliges OK. Mit der Kombination von keychain und gnupg2 (auch in FE verfügbar; muss Version 2 von gnupg sein, da nur die den gpg-agent mit bringt) kannst du dann Signieren automatisieren. Du musst nur 1 mal dem gpg-agent die passphrase des GPG Schlüssels bekannt machen. (Das geht natürlich auch ohne keychain, ist dann aber nicht so herrlich komfortabel und scriptbar).
Zu den anderen von Christoph gefragten Dingen weiß ich nicht so recht zu antworten, da mir nicht klar ist, ob er als ein künftiger Fedora Extras Paketierer fragt, oder die RPMs "nur" für den eigenen Gebrauch schnüren möchte.
Alexander
Am Donnerstag, den 28.07.2005, 03:48 +0200 schrieb Alexander Dalloz:
Ich hoffe, dass in Kürze "keychain" den Weg nach Fedora Extras findet. Einen 1. review Durchgang hatte es schon, nach einer besonderen Anpassung an Fedora warte ich auf nochmaliges OK. Mit der Kombination von keychain und gnupg2 (auch in FE verfügbar; muss Version 2 von gnupg sein, da nur die den gpg-agent mit bringt) kannst du dann Signieren automatisieren. Du musst nur 1 mal dem gpg-agent die passphrase des GPG Schlüssels bekannt machen. (Das geht natürlich auch ohne keychain, ist dann aber nicht so herrlich komfortabel und scriptbar).
Zu den anderen von Christoph gefragten Dingen weiß ich nicht so recht zu antworten, da mir nicht klar ist, ob er als ein künftiger Fedora Extras Paketierer fragt, oder die RPMs "nur" für den eigenen Gebrauch schnüren möchte.
Willst Du mich etwa anwerben? ;-)
Ich habe ein paar Pakete (ca. 50), alles keine großen Sachen, aber ich denke, der ein oder andere kann etwas davon gebrauchen, z. B. KDE-Bluetooth (mehr oder weniger das Paket von Rex Dieter, aber auf einen jungfräulichen FC4 gebaut), fast alle xfce-goodies (auch wenn es davon schon ein paar bei nrpms gibt) und diverse gaim-plugins (u. a. gaim-blogger, meiner persönlichen neuen Killerapplication.)
Wer sich das Ganze mal anschauen will:
http://home.arcor.de/christoph.wickert/fedora/4/i386/repodata und http://home.arcor.de/christoph.wickert/fedora/4/i386/repodata/debug
Einfach die wickerpms.repo von
http://home.arcor.de/christoph.wickert/fedora/wickerpms.repo
runterladen. Da ich einige Pakete habe, die Pakete aus Core upgraden könnten (z.b grip), würde ich kein yum update gegen das Repo durchführen, zumindest nicht, wenn ihr Euch nicht sicher seid, was Ihr tut :-) Aus diesem Grunde habe ich das Repo auch nicht enabled, zum Installieren eines Paketes also bitte
yum --enablerepo=wickerpms install foo
nutzen. Alle Paket funktionieren hier aber problemlos, für Feedback bin ich dankbar, vor allem, weil mich grade der Verdacht beschleicht, daß mit dem GPG-KEY was nicht stimmen _könnte_.
Prinzipiell würde ich schon gerne Pakete für Fedora packen, und wäre Dir, Alexander, dankbar, falls Du mir ein wenig für Fragen etc. zur Verfügung stehen konntest. Bedenken habe ich allerdings wegen der aktualsierten Pakete und weil ich nicht glaube, daß alle meine Pakete die Fedora-Policy erfüllen. :-(
Alexander
Christoph
Am Do, den 04.08.2005 schrieb Christoph Wickert um 23:06:
Hallo Christoph!
Willst Du mich etwa anwerben? ;-)
So gefragt: ja, warum nicht? Ich kann dich zwar nicht in einem förmlichen oder offiziellen Zusammenhang werben, aber gerne bin ich Sprachrohr für die Fedora Community, die tatkräftige Unterstützung beim Ausbau von Fedora Extras gebrauchen kann. Ohne triftigen Grund mag ich da niemanden ausschließen wollen. Die Einladung gilt für alle Interessierten, die das nötige Maß an Sorgfalt und Zuverlässigkeit aufzubringen bereit sind.
Ich habe ein paar Pakete (ca. 50), alles keine großen Sachen, aber ich denke, der ein oder andere kann etwas davon gebrauchen, z. B. KDE-Bluetooth (mehr oder weniger das Paket von Rex Dieter, aber auf einen jungfräulichen FC4 gebaut), fast alle xfce-goodies (auch wenn es davon schon ein paar bei nrpms gibt) und diverse gaim-plugins (u. a. gaim-blogger, meiner persönlichen neuen Killerapplication.)
50 Pakete ist schon eine ganz stattliche Anzahl. Ich selber kapriziere mich auch erst mal auf kleinere Tools. So kann man den Prozess recht überschaubar halten und dabei die Einzelheiten des Verfahrens verinnerlichen.
1. Anlaufpunkt könnte für dich folgende Seite sein:
http://www.fedoraproject.org/wiki/Extras/
Zu beachten ist auch, dass nicht jede Software in Extras eingebracht werden kann, z.B. solche nicht, die nicht open source ist oder unter keinet FOSS Lizenz ((L)GPL, BSD) veröffentlicht ist.
Wer sich das Ganze mal anschauen will:
http://home.arcor.de/christoph.wickert/fedora/4/i386/repodata und http://home.arcor.de/christoph.wickert/fedora/4/i386/repodata/debug
Schaue ich mir mal in Kürze an.
Einfach die wickerpms.repo von
http://home.arcor.de/christoph.wickert/fedora/wickerpms.repo
runterladen. Da ich einige Pakete habe, die Pakete aus Core upgraden könnten (z.b grip), würde ich kein yum update gegen das Repo durchführen, zumindest nicht, wenn ihr Euch nicht sicher seid, was Ihr tut :-) Aus diesem Grunde habe ich das Repo auch nicht enabled, zum Installieren eines Paketes also bitte
Für Fedora Extras scheiden auch solche Pakete aus, die bereits per Fedora Core verfügbar sind.
yum --enablerepo=wickerpms install foo
nutzen. Alle Paket funktionieren hier aber problemlos, für Feedback bin ich dankbar, vor allem, weil mich grade der Verdacht beschleicht, daß mit dem GPG-KEY was nicht stimmen _könnte_.
Prinzipiell würde ich schon gerne Pakete für Fedora packen, und wäre Dir, Alexander, dankbar, falls Du mir ein wenig für Fragen etc. zur Verfügung stehen konntest. Bedenken habe ich allerdings wegen der aktualsierten Pakete und weil ich nicht glaube, daß alle meine Pakete die Fedora-Policy erfüllen. :-(
Frag nur - ich kann allerdings nicht versprechen, zu allem eine gute und richtige Antwort parat zu haben. Michael Schwendt liest ja auch mit, und so wie ich ihn kenne, wird er auch gerne bereits sein, für Aufklärung zu sorgen und Fragen klären helfen.
Christoph
Gruß
Alexander
Am Fr, den 05.08.2005 schrieb Alexander Dalloz um 3:51:
Zu beachten ist auch, dass nicht jede Software in Extras eingebracht werden kann, z.B. solche nicht, die nicht open source ist oder unter keinet FOSS Lizenz ((L)GPL, BSD) veröffentlicht ist.
http://fedoraproject.org/wiki/ForbiddenItems
Um das genauer nachzuliefern.
Alexander
Am Donnerstag, den 28.07.2005, 03:17 +0200 schrieb Stefan Held:
Am Sonntag, den 24.07.2005, 22:17 +0200 schrieb Christoph Wickert:
- Gibt es ein Programm, mit dem ich einigermaßen komfortabel Specfiles
erstellen, vorallem aber verwalten kann? Eigene rpmmacros setzen und so nervige "Kleinigkeiten" wie korrekte Tags im Changelog. Bisher nutze ich meist fedora-newrpmspec, aber das ist ja eine eher einfach gehaltene Vorlage.
Ich kenne da nix sinnvolles außer einem Editor und einem CVS Server.
CVS Server ist etwas overkill für meine Bedürfnisse, aber ein vernünftiger makrofähiger Editor ist schon mal ein Anfang. :-) Danke also für das Makro.
Auch die restlichen Probleme haben sich als als RTFM und UYB (Use your Brain) herausgestellt und konnten somit gelöst werden.
Christoph
de-users@lists.fedoraproject.org
-
Alexander Dalloz -
Christoph Wickert -
Stefan Held