3:17 p.m.
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
8:17 p.m.
Am Sonntag, den 24.07.2005, 22:17 +0200 schrieb Christoph Wickert:
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.
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(a)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 :-)
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.
Das wäre imho zu bevorzugen.
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.
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.
4. 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 :-)
5. 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:
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
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.
--
Stefan Held VI has only 2 Modes:
obi(a)unixkiste.org The first one is for beeping all the time,
IRCNet: Obi_Wan the second destroys the text.
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------
GPG-Keyprint = EAF2 6A65 D102 F2DB 4970 2A67 455B 98F2 572C 3FA9
8:32 p.m.
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.
--
Stefan Held VI has only 2 Modes:
obi(a)unixkiste.org The first one is for beeping all the time,
IRCNet: Obi_Wan the second destroys the text.
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------
GPG-Keyprint = EAF2 6A65 D102 F2DB 4970 2A67 455B 98F2 572C 3FA9
8:48 p.m.
Am Do, den 28.07.2005 schrieb Stefan Held um 3:17:
> 5. 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
--
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp
Serendipity 03:42:29 up 12 days, 8:15, load average: 0.19, 0.22, 0.26
4:06 p.m.
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
8:51 p.m.
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
--
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp
Serendipity 03:49:31 up 1:52, 18 users, 1.65, 1.16, 1.19
10:36 p.m.
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
--
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp
Serendipity 05:33:53 up 3:37, 19 users, 0.25, 0.48, 0.67
7:52 p.m.
Am Donnerstag, den 28.07.2005, 03:17 +0200 schrieb Stefan Held:
Am Sonntag, den 24.07.2005, 22:17 +0200 schrieb Christoph Wickert:
> 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.
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
6832
days inactive
6844
days old
de-users@lists.fedoraproject.org
7 comments
3 participants
participants (3)
-
Alexander Dalloz -
Christoph Wickert -
Stefan Held