[gelöst] Paketerstellung und Präcompilerprobleme

taki · 29 Apr. 2005

Hallo Forum.
Nun hab ich mal wieder eine dieser blöden Probleme, auf die wohl nie jemand antworten wird... Ich gebs trotzdem mal von mir.

Ich habe folgendes Problem:
Meine Anwendung ktvapp läßt sich mit kdevelop prima übersetzen und auch installieren. Ich möchte aber natürlich auch Binary- und Sourcepakete anbieten. Es gelingt aber nicht, aus kdevelop heraus ein Sourcetarball zu erstellen, welches sich fehlerfrei bauen läßt. Das ist aber die Grundvoraussetzung zum Erstellen von RPMs.

Ich fasse mal zusammen, was ich bisher versucht habe und was dabei an Fehlern aufgetreten ist.

Ich kann mit kdevelop unter Projekt / ausliefern & Paket erstellen ein tarball erzeugen. In dem Tarball fehlt aber die Versionsnummer beim Verzeichnisnamen.

Schon mal schlecht zum RPM erstellen. Versucht man jetzt mit kdevelop ein Binär-RPM zu erstellen, kracht es, weil RPM beim Build nicht in das ausgepackte Sourceverzeichnis wechseln kann.
Habe dann das Tarball ausgepackt, die Versionsnummer angehängt und das Verzeichnis wieder eingepackt. Kann eigentlich nicht der Sinn der Sache sein, wenn kdevelop das Paketbauen anbietet, man dann aber selbst das Source-Tarball umpacken muss.

Dann habe ich mit kdevelop unter Projekt / ausliefern & Paket erstellen ein Source-RPM erzeugen können. Das Specfile hatte ich vorher schon erstellt.

Bis hier könnte man meinen, hat es ja geklappt, dann müsste das Erstellen des Binärpakets ja mit einem Knopfdruck erledigt sein. Und nach diesem Knopfdruck wurde das nächste Problem erst sichtbar. Dieses kommt mir vor wie ein Akte X Fall, bin da völlig ratlos.

In dem tarball fehlen in einer Headerdatei folgende zwei Zeilen für den Präprozessor:

Code:

#ifndef PREFS_H
#define PREFS_H

Das führt dazu, dass die Übersetzung mit der Fehlermeldung abbricht, dass Prefs mehrfach definiert sei.

In dem Header im Sourceverzeichnis des kdevelop-Projektordners stehen die zwei Zeilen noch. Im Tarball fehlen sie. Wie kann so etwas passieren?

Aber es kommt noch besser:
Habe im entpackten Buildverzeichnis die fehlenden Zeilen in den Header nachgetragen (mit Copy & Paste aus dem Original-Header) und dann ./configure und make von Hand aufgerufen.

Jetzt beschwert sich der Präcompiler über ein "unterminated ifndef". Was bedeutet das? Ich habe den Header auf Herz und Nieren geprüft, er ist korrekt. Warum kann ich mein Programm nicht aus dem Sourcetarball heraus erstellen?

Ich denke, dass meine kleine Applikation dem einen oder anderen gute Dienste leisten könnte, aber wenn man zum Installieren eine vollständige und eingerichtete kdevelop-Installation benötigt, werden wohl nicht viele diese Applikation testen wollen. Ich wäre darum sehr froh, wenn mir hier jemand weiterhelfen könnte.
Gruß,
Taki

P.S.: ktvapp ist bei kde-apps.org angemeldet. Dort kann man auch das kdevelop-Projektverzeichnis runterladen:

http://www.kde-apps.org/content/show.php?content=23381

oc2pus · 29 Apr. 2005

taki schrieb:
Ich habe folgendes Problem:
Meine Anwendung ktvapp läßt sich mit kdevelop prima übersetzen und auch installieren. Ich möchte aber natürlich auch Binary- und Sourcepakete anbieten. Es gelingt aber nicht, aus kdevelop heraus ein Sourcetarball zu erstellen, welches sich fehlerfrei bauen läßt. Das ist aber die Grundvoraussetzung zum Erstellen von RPMs.

wieso das denn ?

in der %prep Sektion kannst du doch schreiben:
%prep
%setup -q -n <irgendein-name>

-q = quit beim entpacken
-n name des Verzeichnisses zum bauen (meistens steht dort -n <name>-<version> MUSS aber nicht!)

und schon kannst du RPMs bauen wie ein Meister

traffic · 29 Apr. 2005

Ich habe zwar 0 (null) Ahnung vom Programmieren, aber ein wenig Ahnung vom RPM-Bau. Mein bescheidener Beitrag, vielleicht nützt es was:

Zum RPM-Bau muss der Tarball keinen bestimmten Namen haben. Es ist üblich, dass der Name des Tarballs und des beim Entpacken entstehenden Verzeichnisses "%{name}-%{version}" lautet, aber es ist nicht notwendig.

Weil es üblich ist, geht das Programm "rpmbuild" standardmäßig davon aus, dass "%{name}-%{version}" verwendet wird. Um dieses Verhalten zu ändern, kann man im "%setup"-Makro zusätzliche Parameter angeben.

Das nackte "%setup"-Makro geht wie gesagt von "%{name}-%{version}" aus, aber mittels folgender Konstruktion kannst Du dem Programm "rpmbuild" mitteilen, dass die Versionsnummer fehlt:

Code:

%setup -n %{name}

Falls der Name des Verzeichnisses nicht nur die Versionsnummer nicht enthält, sondern völlig anders heißt, dann geht es folgendermaßen:

Code:

%setup -n <Beliebiger_Name>

Schau Dir mal ein paar Source-RPMs von SuSE oder aus beliebigen anderen Quellen an, auf dem Weg kann man ein wenig "learning by doing" oder vielmehr "learning by abschreibing" betreiben.

Oder versuch es mit der Original-Dokumentation von RedHat, da steht wirklich fast alles drin:

http://www.rpm.org/max-rpm/index.html
http://www.tu-chemnitz.de/docs/lindocs/RPM/node12.html
http://www.linuxhaven.de/dlhp/HOWTO/DE-RPM-HOWTO-7.html
http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.html

Die Links stammen aus folgendem Thread:

http://www.linux-club.de/viewtopic.php?t=29782

Ich weiß allerdings nicht, inwieweit sich das mit Deiner Entwicklungsumgebung integriert, weil ich noch nie mit einer Entwicklungsumgebung gearbeitet habe und dies wohl auch mangels entsprechender Kenntnisse nie tun werde.

Vielleicht hilft es Dir trotzdem ein wenig...

EDIT: Mann, bin ich langsam mit dem Schreiben von Beiträgen... :roll: oc2pus war 11 Minuten schneller.

oc2pus · 29 Apr. 2005

traffic schrieb:
EDIT: Mann, bin ich langsam mit dem Schreiben von Beiträgen... :roll: oc2pus war 11 Minuten schneller.

*fg*

ich denke taki kennt den anderen Thread mit den Dokus und in der Kürze liegt die Würze

taki · 29 Apr. 2005

oc2pus schrieb:
traffic schrieb:

EDIT: Mann, bin ich langsam mit dem Schreiben von Beiträgen... :roll: oc2pus war 11 Minuten schneller.

Zum Vergrößern anklicken....

*fg*

...geht mir auch ständig so

oc2pus schrieb:
ich denke taki kennt den anderen Thread mit den Dokus und in der Kürze liegt die WÜrze

Stimmt. Hab die Dokus schon zig mal gelesen, aber das Verständnis setzt sich erst durch ständiges Ausprobieren. Mein Perlscript konnte ich dank Deiner Hilfe schon verpacken. Fertige tarballs hab ich auch schon erfolgreich verpackt. Bei meiner ersten eigenen c++-Applikation tu ich mich noch schwer. So langsam bleibt aber endlich was hängen :wink:

Das mit -n probiere ich nachher aus, damit wäre dann schon mal das erste Problem weg. Danke für die Tips und vor allem Danke für Deine Geduld.

Das mit dem RPM wird schon werden, wenn ich nur erst hinbekomme, dass das Buildverzeichnis sauber kompiliert.

oc2pus · 29 Apr. 2005

noch ein Tipp für RPM-Anfänger:

nutze das Programm rpmlint, es sagt dir was an deinem RPM noch "falsch" ist. Ursprünglich ist es ein Mandrake Programm, es funzt aber auch prima für die SuSE. Man muss nur die config-Datei ordentlich füttern ...

rpmlint gibt es hier:
homepage: http://people.mandrakesoft.com/~flepied/projects/rpmlint/

http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/8.2-i386/RPMS.suser-oc2pus/rpmlint-0.69-0.oc2pus.1.noarch.rpm
http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.1-i386/RPMS.suser-oc2pus/rpmlint-0.69-0.oc2pus.1.noarch.rpm
http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.2-i386/RPMS.suser-oc2pus/rpmlint-0.69-0.oc2pus.1.noarch.rpm

da es ein noarch.rpm ist, sollte es auch für die 9.3 funktionieren .. ansonsten aus src.rpm selber umwandeln

taki · 29 Apr. 2005

Der Tip von oc2pus und traffic hat hingehaun. Mit der -name Option beim setup Makro klappt es mit dem von kdevelop erzeugten tar-Archiv.

Das Präprozessor-Problem entstand durch ein fehlerhaftes Makefile.am. Ich wundere mich aber immer noch, warum der Fehler beim Übersetzen in kdevelop nicht auftritt. Egal, nach Änderung der Makefile.am übersetzt das tarball fehlerfrei und in kdevelop funktioniert es auch weiterhin.

Jetzt muss ich nur noch den Eintrag des Desktopfiles ins Menü hinbekommen. Ich hatte dazu von kdeadmin3.spec abgeschrieben und bei Install folgenden Makroaufruf eingetragen:

%suse_update_desktop_file ktvapp Audiovideo;Recorder TV-Recorder

Nach der Beschreibung über SuSE-RPMs müsste damit meine Anwendung in dem richtigen Untermenü eingetragen werden. Leider funktioniert das nicht. Die Zeile erzeugt folgende Fehlerausgabe:

Code:

...<snip>...
+ /usr/lib/rpm/suse_update_desktop_file.sh ktvapp Audiovideo
ERROR: suse_update_desktop_file: ktvapp has multiple desktop files
error: Bad exit status from /var/tmp/rpm-tmp.89170 (%install)

Das kann ich gar nicht nachvollziehen. Es gibt im gesamten Quellverzeichnis nur eine einzige Desktop-Datei (ktvapp.desktop). Eigentlich dachte ich, das SuSE-Makro zu verwenden wäre sauberer, aber ich werde die Datei wohl von Hand ins Menü eintragen müssen.

Ich werde berichten, wenn das Binary-RPM endlich steht.
Gruß,
Taki

P.S: Noch ein Tip zu kdevelop
Wenn man an der Spec-Datei etwas verändert hat, weil beim letzten Bau was nicht funktionierte, muss man die Datei in den Dialog neu importieren, sonst baut man beim nächsten Mal immer noch mit dem fehlerhaften Specfile!!! Hat mich gerade fünf unnötige Minuten gekostet :?

taki · 29 Apr. 2005

So nahe dran, aber... Was bedeutet das hier nur?

Code:

...<snipp>...
Processing files: ktvapp.kdevelop-debuginfo-0.01-taki.1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/ktvapp.kdevelop-root
error: Installed (but unpackaged) file(s) found:
/opt/kde3/share/applnk/Utilities/ktvapp.desktop
<br />
<br />
RPM build errors:
Installed (but unpackaged) file(s) found:
/opt/kde3/share/applnk/Utilities/ktvapp.desktop
*** Beendet mit Status: 1 ***

Anbei das aktuelle Specfile:
http://www.andreas-silberstorff.de/misc/problem_beim_rpm_erstellen/ktvapp.kdevelop.spec

...und das Makefile.am
http://www.andreas-silberstorff.de/misc/problem_beim_rpm_erstellen/Makefile.am[/url]

[EDIT
Und hier fand ich die Lösung:
http://lists.suse.com/archive/suse-linux-e/2004-Feb/1200.html

Die folgende Zeile fehlte im Specfile:

Code:

/opt/kde3/share/apps/*

Hier wird das Desktopfile vom Makefile abgelegt. RPM will eben das auch wissen!

In zehn Minuten stehen dann das RPM für SuSE 9.3 und das Source-RPM neben dem Tarball im Netz :lol:

, zu finden unter

http://www.kde-apps.org/content/show.php?content=23381

oder unter

http://www.andreas-silberstorff.de/ktvapp/download

oc2pus · 30 Apr. 2005

ein paar Anmerkungen zu deinem SPEC-File:

1.) du solltest mehr macros verwenden...
am Anfang des Spec-files:
%define _prefix /opt/kde3

==> in files
%{_datadir}/applications/kde/*.desktop
%{_datadir}/apps/*
%{_datadir}/doc/HTML/en/*
%{_datadir}/icons/*/*x*/*
%{_datadir}/config.kcfg/ktvapp.kcfg
%{_bindir}/ktvapp
/usr/lib/tvapp/*.pm
/usr/bin/*.pl

statt /etc verwende %{_sysconfdir}
siehe dir diese Datei an, dort sind alle Macros von SuSE definiert: /usr/lib/rpm/suse_macros

Das hat den Vorteil, wenn sich etwas am Filesystem ändert ist dein Spec-file immer noch korrekt, nur die suse-macros wird ausgetauscht !!

2.)
%clean Anweisung:
%clean
rm -rf %{buildroot} <== sehr gefährlich !! nimm mal an deine Variable buildroot ist nicht gesetzt, dann löschst du rekursiv das aktuelle Verzeichnis...
besser so:
[ -d %{buildroot} -a "%{buildroot}" != "" ] && rm -rf %{buildroot}

3.) das mit dem Menuntry und dem Icon wird besser so gelöst:
%suse_update_desktop_file -i %{name} gruppe1 gruppe2 ...
den cat kannst du sparen wenn die Apllikation selber ein desktop-file zur Verfügung stellt.

Beispiel:

Code:

# icon and menu-entry
mkdir -p %{buildroot}%{_datadir}/pixmaps
install -m 644 %{buildroot}%{_datadir}/icons/%{name}.png %{buildroot}%{_datadir}/pixmaps
cat > %{name}.desktop << EOF
[Desktop Entry]
Comment=blah blah
Comment[de]=blah blah
Exec=%{name}
GenericName=
GenericName[de]=
Icon=%{name}
MimeType=
Name=....
Name[de]=....
Path=
StartupNotify=true
Terminal=false
Type=Application
EOF
%suse_update_desktop_file -i %{name} AudioVideo Music

...
%files
%{_datadir}/pixmaps/%{name}.png
%{_datadir}/applications/%{name}.desktop
....

zum einlesen in die SuSE-Regeln:
http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.html

taki · 30 Apr. 2005

Das mit den SuSE Regeln hab ich gelesen. Leider hat %suse_update_desktop_file nicht funktioniert (sieh mal drei Posts weiter oben).

Ich sehe gerade, woran es lag: "-i %{name}" fehlte.

Ich werde mir das aber nächste Woche noch mal genauer ansehen und noch etwas nachbessern. Jetzt muss ich nämlich weg in den Norden zu 'ner Konfirmation. Werde erst Sonntag abend wieder an meinem Rechner sein können.

Danke schon mal für die Hinweise.
Gruß,
Taki

%suse_update_desktop_file -i %{name} AudioVideo TV

... nicht Music, TV, so müsste es hinhauen.

taki · 2 Mai 2005

oc2pus schrieb:
ein paar Anmerkungen zu deinem SPEC-File:

1.) du solltest mehr macros verwenden...
am Anfang des Spec-files:
%define _prefix /opt/kde3

jepp, getan.

oc2pus schrieb:
==> in files
%{_datadir}/applications/kde/*.desktop
%{_datadir}/apps/*
%{_datadir}/doc/HTML/en/*
%{_datadir}/icons/*/*x*/*
%{_datadir}/config.kcfg/ktvapp.kcfg
%{_bindir}/ktvapp
/usr/lib/tvapp/*.pm
/usr/bin/*.pl

jepp, auch das

oc2pus schrieb:
statt /etc verwende %{_sysconfdir}

... und noch mal volles ACK.

oc2pus schrieb:
siehe dir diese Datei an, dort sind alle Macros von SuSE definiert: /usr/lib/rpm/suse_macros

Das hat den Vorteil, wenn sich etwas am Filesystem ändert ist dein Spec-file immer noch korrekt, nur die suse-macros wird ausgetauscht !!

Genau, deshalb hab ich die Vorschläge alle so übernommen. Danke dafür.

oc2pus schrieb:
2.)
%clean Anweisung:
%clean
rm -rf %{buildroot} <== sehr gefährlich !! nimm mal an deine Variable buildroot ist nicht gesetzt, dann löschst du rekursiv das aktuelle Verzeichnis...
besser so:
[ -d %{buildroot} -a "%{buildroot}" != "" ] && rm -rf %{buildroot}

Oh ja. Will nicht schuld sein, wenn ein freundlicher Mensch das SRPM für eine andere Version neu übersetzen will und hinterher kein HOME mehr hat...

oc2pus schrieb:
3.) das mit dem Menuntry und dem Icon wird besser so gelöst:
%suse_update_desktop_file -i %{name} gruppe1 gruppe2 ...
den cat kannst du sparen wenn die Apllikation selber ein desktop-file zur Verfügung stellt.

Beispiel:

Code:
# icon and menu-entry
mkdir -p %{buildroot}%{_datadir}/pixmaps
install -m 644 %{buildroot}%{_datadir}/icons/%{name}.png %{buildroot}%{_datadir}/pixmaps
cat > %{name}.desktop << EOF
[Desktop Entry]
Comment=blah blah
Comment[de]=blah blah
Exec=%{name}
GenericName=
GenericName[de]=
Icon=%{name}
MimeType=
Name=....
Name[de]=....
Path=
StartupNotify=true
Terminal=false
Type=Application
EOF
%suse_update_desktop_file -i %{name} AudioVideo Music

Das Icon steht nicht direkt unter ...share/icons, sondern unter .../share/icons/hicolor/32x32/apps. Ein Desktopfile ist in der Source vorhanden. Es wird in der %files-Sektion installiert. Wie Du sagst, entfällt daher das cat. Ausserdem entfällt %suse_update_desktop_file komplett, da sonst versucht wird, das Desktopfile zwei mal zu installieren!

Code:

+ mkdir -p /var/tmp/ktvapp.kdevelop-root/opt/kde3/share/pixmaps
+ install -m 644 /var/tmp/ktvapp.kdevelop-root/opt/kde3/share/icons/hicolor/32x32/apps/ktvapp.png /var/tmp/ktvapp.kdevelop-root/opt/kde3/share/pixmaps
+ /usr/lib/rpm/suse_update_desktop_file.sh -i ktvapp AudioVideo TV
ERROR: suse_update_desktop_file: ktvapp has multiple desktop files

Ein Blick nach /opt/kde3/share/pixmap offenbart...

existiert nicht. Hmm. Ich lasse besser das ganze mit dem Menüeintrag weg. Der hat ja schon vorher richtig funktioniert.

oc2pus schrieb:
...
%files
%{_datadir}/pixmaps/%{name}.png
%{_datadir}/applications/%{name}.desktop
....

Leider kann ich %{name} nicht anwenden, ohne wieder am tarball rumfummeln zu müssen. kdevelop hängt seinen eigenen Namen an den Anwendungsnamen ran. %{name} ist nicht ktvapp, sondern ktvapp.kdevelop. Das wird noch eine Weile so bleiben. Also steht hier erst mal noch der ausgeschriebene Name 'ktvapp'.

Die Änderungen sind im RPM für Version 0.02 enthalten.

oc2pus · 2 Mai 2005

du solltest ja auch nicht alles "akribisch" übernehmen

es sollte dir nur als Beispiel dienen. manchmal muss man ein Macro "Macro" sein lassen und einen eigenen Namen hinschreiben. Das ist ok, bei kleinen SPEC-Files und einem Entwickler ... aber es gibt auch andere viel längere SPEC-Files. Und dann ist man froh wenn eine Änderung an einer Stelle zentral durchgeführt wird und durch die Macros korrekt substituiert werden ... (Beispiel nvu oder Open-Sound-World, die compilieren auf meinem laptop ca 30-50 Minuten und es ist dann ärgerlich wenn in der %files Anweisung ein kleiner Bug ist ...)

Tip:
rpm --short-circuit -bi (führt nur den %install-step aus) das kann man dann solange wiederholen bis alles korrekt ist, spart das neu-compile

Tip:
wenn ein makefile das Icon an die falsche Stelle kopiert .. lösche es und installiere es SuSE-like neu (siehe mein Beispiel oben)

In einem Specfile dürfen shell-befehle stehen.

also mv %{buildroot}/xxxx/icon/32x32/icon.png %{buildroot}%{_datadir}/pixmaps/%{name}.png
und rm <falsches.desktop>

taki · 3 Mai 2005

oc2pus schrieb:
Tip:
wenn ein makefile das Icon an die falsche Stelle kopiert .. lösche es und installiere es SuSE-like neu (siehe mein Beispiel oben)

In einem Specfile dürfen shell-befehle stehen.

also mv %{buildroot}/xxxx/icon/32x32/icon.png %{buildroot}%{_datadir}/pixmaps/%{name}.png
und rm <falsches.desktop>

Schon verstanden, aber es bleibt dabei:

{_datadir}/pixmaps/ alias "/opt/kde3/share/pixmaps" gibt es nicht.

Da will ich denn auch besser nichts hinkopieren, sonst wäre mein Icon das einzige in diesem Pfad. Das Desktop-File und die Icons sind von dem kdevelop-Template bereits vorgegeben. Ich musste nur die Icons in einem Editor ändern und im Desktopfile die Beschreibung anpassen, die Gruppe für den Menüeintrag ändern und die unpassenden Übersetzungen rausschmeissen. Der Menüeintrag landet auch ohne das SuSE-Makro genau da, wo er hingehört, nämlich unter Multimedia/TV.

[gelöst] Paketerstellung und Präcompilerprobleme

taki

Advanced Hacker

oc2pus

Ultimate Guru

traffic

Guru

oc2pus

Ultimate Guru

taki

Advanced Hacker

oc2pus

Ultimate Guru

taki

Advanced Hacker

taki

Advanced Hacker

oc2pus

Ultimate Guru

taki

Advanced Hacker

taki

Advanced Hacker

oc2pus

Ultimate Guru

taki

Advanced Hacker