[per RPM gelöst] tar.gz aus "make install" erzeugen

josef-wien · 25 Juni 2016

Gefühlsmäßig habe ich so meine Zweifel, ob das dokumentiert wird. Logisch erscheinen mir das Änderungslog oder eine eigene readme-Datei. Übrigens muß nicht unbedingt der Quellcode verändert werden, mann kann auch patches dazugeben. Wie ich oben nachträglich ergänzte, ist es nicht erfolgt.

LUH 3417 schrieb:
me-tv-1.3.6-3.381.src.rpm oder me-tv-1.3.6-1.125.src.rpm

Bei der Release-Nummer hat wohl jeder im build service seine Vorstellungen, ableiten kannst Du daraus nichts. Der einzige Unterschied ist übrigens die Release-Angabe im spec file. Wenn Du jetzt in "Deinem" spec file eine ganz andere Release-Angabe machst, mit

Code:

rpmbuild -ba me-tv.spec

je ein neues binary und source packages erstellst und diese beiden im build service zur Verfügung stellst, dürfen sich ein paar Leute über Deine Release-Angabe wundern.

abgdf · 25 Juni 2016

josef-wien schrieb:
abgdf schrieb:

Seit wann

Zum Vergrößern anklicken....

Vermutlich seit 1992, seit damals gibt es die GNU Coding Standards.

Ach ja, dann wäre ja schon seit 1992 alles klar. Ist es aber nicht:

http://stackoverflow.com/questions/1439950/whats-the-opposite-of-make-install-ie-how-do-you-uninstall-a-library-in-lin

Watch out for files that might also have been installed by other packages. Simply deleting these files (one interpretation of "manually reversing those steps") could break the other packages. This is (one of many reasons) why package managers were invented. – Merlyn Morgan-Graham

checkinstall baut Dir halt ein rpm. Das kann man dann gefahrlos wieder deinstallieren (rpm -e ...), wobei etwaige Abhängigkeiten geprüft werden - und nicht, daß einfach alles ungeprüft gelöscht wird wie mit "make uninstall".

Anonymous · 26 Juni 2016

LUH 3417 schrieb:
Hinter den verschiedenen Endnummern z.B. me-tv-1.3.6-3.381.src.rpm oder me-tv-1.3.6-1.125.src.rpm müsste doch eine Logik oder Historie stecken. Oder ist das Willkür?

Dahinter steckt wirklich eine Logik, auch wenn die ganz simpel ist. Mit jedem Kompiliervorgang auf den Buildmaschienen (zb https://build.opensuse.org/) und damit dem Neuerstellen des Paketes wird das "build" oder die Release-Markierung automatisch gesetzt.

Normaler Weise handhabt der Build Service die Release-Markierung automatisch. Der Inhalt des Feldes Release: wird durch das Tupel CI_CNT.B_CNT ersetzt, worin CI_CNT eine Zahl von Commits und B_CNT eine Zahl von Umbauten sind (wenn der Neubau ausgelöst wird).

Es gibt also bei jedem neu kompilieren eine neue Nummer hinten. bei zB "3.381" gab es 3 (Commits) Änderungen und seit dem ist das aber schon 381 mal neu kompiliert worden. Das neu Kompilieren kann händisch meistens aber automatisch von den Buildmaschienen selbst angestoßen wenn zB abhängige Pakete neu erstellt wurden, Am Paket selbst hat sich nicht geändert, aber es könnten Änderungen in irgend einem der abhängigen Pakten gegeben haben.
Für die 3 Änderungen sollten wenn sauber gearbeitet wurde, Hinweise in den "Paketname.changes" auf den Buildmaschinen manchmal auch Notizen in der SPEC Datei zu finden sein. ( wird aber bei schlampig gewarteten Projekten auch gerne mal vergessen) Das sind im wesentlichen die Änderungen an der SPEC Datei selbst. ( Patche dazu oder weg, Abhängigkeiten , Erweiterungen und Korrekturen ... )

make unistall, gibts wirklich, sollte auch bei einfacheren Projekten deren Makefile mittels Autoconf, Automake, und Libtool erstellt werden sauber funktionieren, (Finger weg wenn ihr nicht wisst was ihr da tut.)
checkinstall bei einfachen Sachen eine Notlösung vielleicht, aber eigentlich veraltet, wer dort der Meinung ist schon bei leicht komplexen Zusdammenhängen die Abhängigkeiten von Paketen sauber manuell richtig und auch wirklich plausibel und funktionierend für die Paketmanager einzutragen :irre:

, der sollte auch in der Lage sein, eine SPEC-Datei selbst zu schreiben oder eine vorhandene anzupassen und mit rpmbuild zu arbeiten.

robi

abgdf · 26 Juni 2016

robi schrieb:
checkinstall bei einfachen Sachen eine Notlösung vielleicht, aber eigentlich veraltet

Ein Programm, dessen Funktion nicht durch ein anderes ersetzt wird, kann nicht veraltet sein, da es dann immer noch gebraucht wird.

Anonymous · 27 Juni 2016

Vielen Dank für die Erklärungen zu rpmbuild!

Wenn ich die me-tv.spec ändere, also BuildRequires: libgnomeuimm-devel rausnehme, dann müsste ich doch eine neue Release-Nummer angeben. Aber welche?
Auf Packman gibt es für openSUSE 12.2 sogar me-tv-1.3.6-7.87.src.rpm: http://packman.links2linux.de/package/me-tv/504394

robi schrieb:
Es gibt also bei jedem neu kompilieren eine neue Nummer hinten. bei zB "3.381" gab es 3 (Commits) Änderungen und seit dem ist das aber schon 381 mal neu kompiliert worden.

Wo findet man dann diese Commits, wenn die me-tv.spec (außer der Release-Nummer) und der Quellcode immer identisch sind? Bei dem Paket auf Packman wären das ja 7 Commits.

josef-wien schrieb:
Wenn Du jetzt in "Deinem" spec file eine ganz andere Release-Angabe machst, mit

Code:

rpmbuild -ba me-tv.spec

je ein neues binary und source packages erstellst und diese beiden im build service zur Verfügung stellst, dürfen sich ein paar Leute über Deine Release-Angabe wundern.

Wenn ich das sauber dokumentiere muss sich niemand wundern. Würdet Ihr mich dabei unterstützen?
Lesestoff?

josef-wien · 27 Juni 2016

Dein Beispiel von Packman zeigt:
- Version für 12.2=http://packman.links2linux.de/download/me-tv/1791783/me-tv-1.3.6-7.87.x86_64.rpm
- Version für 12.3=http://packman.links2linux.de/download/me-tv/2056018/me-tv-1.3.6-2.1.x86_64.rpm
Das bedeutet, wenn Du openSUSE von 12.2 auf 12.3 aktualisierst, wird dieses Paket nicht aktualisiert, denn im Repo von 12.3 ist formal eine ältere Version vorhanden (obwohl vermutlich beide mit dem Original-Quellcode übersetzt wurden, aber das untersuche ich nicht auch noch). In meiner "openSUSE-Zeit" mußte ich mich nicht nur bei Packman immer wieder mit solchen Problemen herumschlagen.

Nachdem es Deine erste Release ist und diese den unveränderten Quellcode der me-tv-Entwickler enthält, müßte 1 oder 1.0 verwendet werden, dann mußt Du allerdings gezielt ein downgrade auf Deine Version ausführen.

Wie immer im Leben gilt auch hier: Grau ist alle Theorie ...

P. S. Beim Thema build service kann ich Dir nicht helfen.

Anonymous · 27 Juni 2016

LUH 3417 schrieb:
Wo findet man dann diese Commits, wenn die me-tv.spec (außer der Release-Nummer) und der Quellcode immer identisch sind? Bei dem Paket auf Packman wären das ja 7 Commits.

zu finden ist sowas wie oben geschrieben auf den Buildmaschinen.
dort hast du die "Files changed" Dateien https://pmbs-api.links2linux.org/package/revisions/Multimedia/me-tv?showall=1
und hier nochmal alles zusammen https://pmbs-api.links2linux.org/package/show/Multimedia/me-tv
sowohl die me-tv.changes Datei , die aktuelle Spec sowie unten auch nochmal "File changed" mit den Differenzen vom SPEC und von me-tv.changes

Jetzt frag nur nicht wie du jetzt genau herausbekommst was jetzt für ein "Change Stand" jetzt genau gültig ist für eine alte nicht mehr aktuelle Version,

Das ist oftmals ganz schönes Fummelwerk bis man sich da rückwärts oder vorwärts durch verschiedene Änderungen durchgewühlt hat.

Wenn du das Ganze dann mit der Buildmaschine einer anderen Paketquelle vergleichst. zb. https://build.opensuse.org/package/show/multimedia:apps/me-tv
wirst du feststellen das sich die Releasenummern hier ganz anders entwickeln. Aus diesem Grund gibt es die Priorisierung der Paketqellen ansonsten gäbe es ein ziemliches Durcheinander, wie man auch schön immer wieder erleben kann, wenn bei Usern viele Paketquellen mit teilweise identischen Inhalten und falscher Priorisierung vorhanden sind.
Wenn du selbst eigene Pakete bauen willst, die irgendwo in Konqurenz zu anderen Paketquellen stehen, bleibt dir nichts anders übrig als die in einem eigenem Repository anzubieten, dann ist es egal mit welchen Releasenummern du hochkommst, (Hauptsache sie sind Distributionskonform.) die Auswahl welche Quelle dann genommen wird regelt die Prio der Repositories.
Alternativ, für dich selbst, kann du auch deine eigenen Pakete unabhängig deiner Releasnummerierung force installieren und die andern aus offiziellen Repos blocken, damit sie nicht bei jedem Update durch andere aus den offiziellen Repos wieder ausgetauscht werden. Aber weniger zu empfehlen wenn größere Äbhängikeiten da dranhängen und du nicht alle abhängigen Pakete auch noch selbst warten willst.

robi

Anonymous · 28 Juni 2016

Danke. Ich baue me-tv-1.3.6 besser erst mal nur für mich selbst. openSUSE Build Service ist doch etwas aufwendiger.

Gibt es auch ein grafisches Tool, um Metadaten einer RPM-Datei anzuschauen? In Ark oder file-roller z.B. wird das gar nicht angezeigt.
Im Kofler 2016 wird nur rpm genannt:

Code:

rpm -qpli me-tv-1.3.6-1.125.x86_64.rpm 
Name        : me-tv
Version     : 1.3.6
Release     : 1.125
Architecture: x86_64
Install Date: (not installed)
Group       : Hardware/TV
Size        : 12030393
License     : GPL-3.0+
Signature   : (none)
Source RPM  : me-tv-1.3.6-1.125.src.rpm
Build Date  : Fri Jun 24 10:57:29 2016
Build Host  : linux-g7hl.suse
Relocations : (not relocatable)
URL         : https://launchpad.net/me-tv
Summary     : Me TV DVB application
Description :
Me TV is a digital television (DVB) viewer for GNOME/GTK
Me TV was developed for the modern digital lounge room with
a PC for a media centre that is capable of normal PC tasks
(web surfing, word processing and watching TV). It is not
designed to be a full-blown media centre, such as MythTV,
but will integrate well with an existing GNOME desktop.
Distribution: (none)
/usr/bin/me-tv
/usr/bin/me-tv-player
/usr/share/GConf/schemas/me-tv.schemas
/usr/share/applications/me-tv.desktop
/usr/share/doc/packages/me-tv
/usr/share/doc/packages/me-tv/AUTHORS
/usr/share/doc/packages/me-tv/COPYING
/usr/share/doc/packages/me-tv/README
/usr/share/man/man1/me-tv-player.1.gz
/usr/share/man/man1/me-tv.1.gz
/usr/share/me-tv
/usr/share/me-tv/glade
/usr/share/me-tv/glade/me-tv.ui
/usr/share/me-tv/glade/me-tv.xpm
/usr/share/pixmaps/me-tv-recording.png
/usr/share/pixmaps/me-tv-recording.xpm
/usr/share/pixmaps/me-tv.png
/usr/share/pixmaps/me-tv.xpm

zypper info me-tv-1.3.6-1.125.x86_64.rpm klappt nicht.

abgdf · 28 Juni 2016

Versteh' ich nicht: Welche Daten willst Du denn, die "rpm -qpli" nicht liefert?

Und was um alles in der Welt hast Du gegen "checkinstall", wenn es nur darum geht, schnell mal ein Paket für sich selbst zu bauen?

Sauerland · 28 Juni 2016

zypper info me-tv-1.3.6-1.125.x86_64.rpm klappt nicht.

Schöne Fehlermeldung......
Sagt alles.

josef-wien · 28 Juni 2016

LUH 3417 schrieb:
ein grafisches Tool

Konqueror (über KRPMView) von KDE 3 und KPackage von Trinity können es, aber der Informationsgehalt von rpm ist größer. Bei den verspielten Oberflächen wie KDE ab 4 weiß ich es nicht. Eher unelegant kann es der (textbasierte) Midnight Commander.

LUH 3417 schrieb:
zypper info me-tv-1.3.6-1.125.x86_64.rpm klappt nicht.

Meine Erinnerung meint, daß es

Code:

zypper info me-tv

heißen (und sich das Paket in einem Repo befinden) muß. Was willst Du herauslesen, was rpm nicht bietet?

Anonymous · 29 Juni 2016

@abgdf
Nichts gegen "checkinstall", aber ich möchte mich nicht in 2 Lösungen gleichzeitig einarbeiten.

@Sauerland
Mit zypper info me-tv bekomme ich nur Info zum installierten Paket.
Kann zypper auch mit lokalen RPM-Dateien umgehen?

@josef-wien
Ich mag das nicht, wenn mir Programme etwas verschweigen. Ist doch wie unter MS-Windows: Man hat nur Fenster, wo man hineinschauen kann.
Linux hat quasi Türen. Man kann hineingehen und sich richtig umsehen.

Ich möchte wissen, wie ein RPM genau aufgebaut ist. Mit dem Editor vi sehe ich ab Zeile 6 das hier:

Code:

me-tv^@1.3.6^@1.125^@Me TV DVB application^@Me TV is a digital television (DVB) viewer for GNOME/GTK
Me TV was developed for the modern digital lounge room with
a PC for a media centre that is capable of normal PC tasks 
(web surfing, word processing and watching TV). It is not
designed to be a full-blown media centre, such as MythTV,
but will integrate well with an existing GNOME desktop.^@^@^@Wlõùlinux-g7hl.suse^@^@·<91>¹GPL-3.0+^@Hardware/TV^@https://launchpad.net/me-tv^@linux^@x86_64^@mkdir -p /usr/share/GConf/schemas/outdated
if test -f /usr/share/GConf/schemas/me-tv.schemas ; then
    cp -f /usr/share/GConf/schemas/me-tv.schemas /usr/share/GConf/schemas/outdated/
elif test -f /usr/share/gconf/schemas/me-tv.schemas ; then
    # Migration from /usr/share/gconf/schemas to /usr/share/GConf/schemas. Can be removed for openSUSE 11.4+3
    cp -f /usr/share/gconf/schemas/me-tv.schemas /usr/share/GConf/schemas/outdated/
elif test -f /etc/gconf/schemas/me-tv.schemas ; then
    # Migration from /etc/gconf/schemas to /usr/share/GConf/schemas. Can be removed for openSUSE 12.2
    cp -f /etc/gconf/schemas/me-tv.schemas /usr/share/GConf/schemas/outdated/
fi
^@if test "$1" = "0"; then
    if test -x /usr/bin/gconftool-2 ; then
        export GCONF_CONFIG_SOURCE=`/usr/bin/gconftool-2 --get-default-source`
    fi    
    if test -x /usr/bin/gconftool-2 ; then
        if test -f /usr/share/GConf/schemas/outdated/me-tv.schemas ; then
            /usr/bin/gconftool-2 --makefile-uninstall-rule /usr/share/GConf/schemas/outdated/me-tv.schemas >/dev/null
        elif test -f /usr/share/GConf/schemas/me-tv.schemas ; then
            /usr/bin/gconftool-2 --makefile-uninstall-rule /usr/share/GConf/schemas/me-tv.schemas >/dev/null
        fi    
    fi    
    rm -f /usr/share/GConf/schemas/outdated/me-tv.schemas
    rmdir /usr/share/GConf/schemas/outdated 2>/dev/null || true
fi

Gibt es da vielleicht noch was besseres als einen Texteditor, um die Metadaten einer RPM-Datei anzuschauen?
Die Nutzdaten zeigt mir ein Packprogramm. Aber eben nur die Nutzdaten.

josef-wien · 29 Juni 2016

Das ist zuerst ein Auszug aus dem header und dann die Ausgabe der Installations-Skripte (die Dir auch

Code:

rpm -q --scripts --triggers paketname        (nur für installierte Pakete)
rpm -qp --scripts --triggers dateiname.rpm   (für alle Pakete)

zeigt).

LUH 3417 schrieb:
Ich mag das nicht, wenn mir Programme etwas verschweigen.

Jedes Programm beschränkt sich auf das, was die Entwickler für wichtig halten. Außer rpm fällt mir nur der bereits erwähnte Midnight Commander zur (vermutlich) allumfassenden Information ein.

P. S. Glaube robi und mir, und vergiß das nicht empfehlenswerte checkinstall.

Anonymous · 29 Juni 2016

josef-wien schrieb:
LUH 3417 schrieb:

Ich mag das nicht, wenn mir Programme etwas verschweigen.

Zum Vergrößern anklicken....

Jedes Programm beschränkt sich auf das, was die Entwickler für wichtig halten.

Ich meine auch, dass nach rpm -i me-tv-1.3.6-1.125.src.rpm im Verzeichnis ~/rpmbuild/ nur die Dateien zu finden sind, die auch ein Packprogramm anzeigt.

Dagegen zeigt:

Code:

$ rpm -qpli me-tv-1.3.6-1.125.src.rpm
Name        : me-tv
Version     : 1.3.6
Release     : 1.125
Architecture: i586
Install Date: (not installed)
Group       : Hardware/TV
Size        : 463335
License     : GPL-3.0+
Signature   : DSA/SHA1, Sa 24 Aug 2013 09:44:02 CEST, Key ID 5f3d540f3a802234
Source RPM  : (none)
Build Date  : Sa 24 Aug 2013 09:43:41 CEST
Build Host  : cloud105
Relocations : (not relocatable)
Vendor      : obs://build.opensuse.org/multimedia
URL         : https://launchpad.net/me-tv
Summary     : Me TV DVB application
Description :
Me TV is a digital television (DVB) viewer for GNOME/GTK
Me TV was developed for the modern digital lounge room with
a PC for a media centre that is capable of normal PC tasks
(web surfing, word processing and watching TV). It is not
designed to be a full-blown media centre, such as MythTV,
but will integrate well with an existing GNOME desktop.
Distribution: multimedia:apps / openSUSE_Factory
me-tv-1.3.6.tar.gz
me-tv-1.3.6.tar.gz.asc
me-tv.spec

Und (mit Warnung 1.Zeile):

Code:

$ rpm -qpli me-tv-1.3.6-3.381.src.rpm 
warning: me-tv-1.3.6-3.381.src.rpm: Header V3 DSA/SHA1 Signature, key ID 602f90b9: NOKEY
Name        : me-tv
Version     : 1.3.6
Release     : 3.381
Architecture: x86_64
Install Date: (not installed)
Group       : Hardware/TV
Size        : 463335
License     : GPL-3.0+
Signature   : DSA/SHA1, Di 22 Sep 2015 07:43:38 CEST, Key ID ae8086ba602f90b9
Source RPM  : (none)
Build Date  : Di 22 Sep 2015 07:43:28 CEST
Build Host  : build72
Relocations : (not relocatable)
Vendor      : obs://build.opensuse.org/home:lnussel
URL         : https://launchpad.net/me-tv
Summary     : Me TV DVB application
Description :
Me TV is a digital television (DVB) viewer for GNOME/GTK
Me TV was developed for the modern digital lounge room with
a PC for a media centre that is capable of normal PC tasks
(web surfing, word processing and watching TV). It is not
designed to be a full-blown media centre, such as MythTV,
but will integrate well with an existing GNOME desktop.
Distribution: home:lnussel:me-tv / openSUSE_Factory
me-tv-1.3.6.tar.gz
me-tv-1.3.6.tar.gz.asc
me-tv.spec

Erst hier finde ich wirkliche Unterschiede zwischen den beiden src.rpm.

rpm -qp --scripts --triggers me-tv-1.3.6-1.125.src.rpm liefert aber gar keine Augabe,
rpm -qp --scripts --triggers me-tv-1.3.6-3.381.src.rpm nur die Warnung wie vorher.

Gibt es für Quell-RPMs keine Programmier/Hilfswerkzeuge außer rpm / rpmbuild selbst und der Paket.spec Datei?

abgdf · 29 Juni 2016

LUH 3417 schrieb:
@abgdf
Nichts gegen "checkinstall", aber ich möchte mich nicht in 2 Lösungen gleichzeitig einarbeiten.

josef-wien schrieb:
P. S. Glaube robi und mir, und vergiß das nicht empfehlenswerte checkinstall.

Also nochmal: checkinstall ist ein Frontend-Skript für rpmbuild (also gar keine "zweite Lösung"). Warum macht man sowas? Weil keiner Lust hat, sich mit spec-files herumzuschlagen, wenn es nicht wirklich sein muß.
Wenn man aus einem Source-Code ein rpm haben will, tippt man einfach

Code:

./configure; make; checkinstall

beantwortet ein/zwei Fragen und guckt, was passiert. Nicht selten spuckt er dann einfach das gewünschte rpm aus und fertig. Keine Einarbeitung, keine spec-file-Kopfschmerzen. (Abgesehen von dem dummen Bug, um den man sich ggf. noch kümmern muß. Kann aber gut sein, daß der in Leap schon gefixt wurde.)

LUH 3417 schrieb:
Gibt es für Quell-RPMs keine Programmier/Hilfswerkzeuge außer rpm / rpmbuild selbst und der Paket.spec Datei?

Ich denke nicht. Was vermißt Du denn?

Anonymous · 29 Juni 2016

abgdf schrieb:
LUH 3417 schrieb:

Gibt es für Quell-RPMs keine Programmier/Hilfswerkzeuge außer rpm / rpmbuild selbst und der Paket.spec Datei?

Zum Vergrößern anklicken....

Ich denke nicht. Was vermißt Du denn?

Na sowas wie ein Makefile unter C z.B., das dann auch alle Metadaten eines Binär-RPMs erzeugt, die in der Datei Paket.spec im Quell-RPM nicht drinstehen.

So ganz einfache Makefiles habe ich schon selber geschrieben. Man kann ja Makros definieren und dann für die Abhängigkeiten auch einfach die in make eingebauten Regeln verwenden.
Aber bei den RPM-Metadaten sieht das für mich so kryptisch (=verborgen) aus. Ein src.rpm besitzt ja auch schon Metadaten. Woher kommen die? = Henne-Ei-Problem.

josef-wien · 29 Juni 2016

Die Metadaten eines src.rpm sind dessen Metadaten und nichts anderes. Ein src.rpm enthält keine Installations-Skripte, denn was bei der Installation des src.rpm passiert, ist durch den Typ src.rpm fest vorgegeben.

Die Metadaten eines zu erstellenden src.rpm oder binary rpm sind (abgesehen von jenen, die automatisch erzeugt werden, wie z. B. Datum und Uhrzeit) im spec file definiert. Zur Erzeugung eines src.rpm oder binary rpm brauchst Du nichts anderes als einen spec file (der auch genau festlegt, was jeweils passieren soll), das Archiv mit dem übersetzungsfähigen Quellcode und gegebenenfalls patches dazu, und diese Dateien müssen nicht von einem src.rpm stammen. Somit stimmt Deine Aussage:

LUH 3417 schrieb:
Ich meine auch, dass nach rpm -i me-tv-1.3.6-1.125.src.rpm im Verzeichnis ~/rpmbuild/ nur die Dateien zu finden sind, die auch ein Packprogramm anzeigt.

_______

P. S. Du kannst sogar ein binary rpm erzeugen, bei dessen Erstellung nichts übersetzt wird, sondern nur Dateien aufgenommen bzw. Abhängigkeiten und Bereitstellungen definiert werden, aber ich will Dich nicht verwirren.

Anonymous · 29 Juni 2016

josef-wien schrieb:
P. S. Du kannst sogar ein binary rpm erzeugen, bei dessen Erstellung nichts übersetzt wird, sondern nur Dateien aufgenommen bzw. Abhängigkeiten und Bereitstellungen definiert werden, aber ich will Dich nicht verwirren.

Nein, das leuchtet mir ein. Es kann sich ja um eine Script-Datei handeln, die später per RPM im System installiert werden soll.

Verwirrend war für mich, dass in den Metadaten von z.B. me-tv-1.3.6-1.125.src.rpm Infos zu finden sind, die gar nicht in der Datei me-tv.spec stehen. (Architecture, Signature, Vendor) Diese Metadaten müssen also beim Build-Vorgang aus einer anderen Quelle als me-tv.spec oder nachträglich hinzugefügt worden sein.

P.S. Ich habe jetzt mal die Datei me-tv.spec entsprechend neu an die nötigen Pakete angepasst, Release-Nummer 1.0 vergeben und per rpmbuild -bs rpmbuild/SPECS/me-tv.spec nur ein neues src.rpm erstellen lassen. Ich denke, soweit ist alles klar. Vielen Dank nochmals, auch an robi. :thumbs:

josef-wien · 29 Juni 2016

LUH 3417 schrieb:
Architecture, Signature, Vendor

Damit der spec file architekturunabhängig ist, wird auf die Angabe von "BuildArch:" verzichtet, rpmbuild nimmt dann die Architektur, unter der es läuft. Ein src.rpm ist zwar architekturunabhängig, da ein 64 Bit-Paket aber nicht auf einem 32 Bit-System installierbar ist, ist unser Beispiel offenbar auf einem 32 Bit-System entstanden (im Gegensatz zu Deiner Version). "Vendor:" steuert sicher das build service bei, "Signature:" vermutlich auch, aber Details muß ein build service-Kundiger liefern.

P. S. Daß der spec file schon ziemlich alt ist, zeigt auch die Zeile "Recommends: libxine1-codecs", denn dieses empfohlene Paket gibt es schon lange nicht mehr.

Anonymous · 1 Juli 2016

Die letzten beiden Links 3 & 4 von Dir zum Lesestoff rpmbuild sind leider schon veraltet und der Deutsche mit vielen Tippfehlern.
Ich habe dann den hier genommen: https://fedoraproject.org/wiki/How_to_create_an_RPM_package
und: http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html
und dann gleich noch einen Patch für die deutsche Übersetzung in rpmbuild/SOURCES/ eingefügt.

Wenn man/frau das mit dem rpmbuild mal kapiert hat, macht das richtig Spaß.

$ cat rpmbuild/SPECS/me-tv.spec

Code:

# norootforbuild

%bcond_with gstreamer

Name:           me-tv
BuildRequires:  fdupes
BuildRequires:  gnome-doc-utils-devel
BuildRequires:  intltool
BuildRequires:  glibmm2-devel
BuildRequires:  gconfmm-devel
BuildRequires:  gnet-devel
BuildRequires:  sqlite3-devel
BuildRequires:  libxine-devel
%if %{with gstreamer}
BuildRequires:  gstreamer-0_10-devel
BuildRequires:  gstreamer-0_10-plugins-base-devel
%endif
BuildRequires:  gcc-c++
BuildRequires:  update-desktop-files
BuildRequires:  libunique1-devel
BuildRequires:  dbus-1-glib-devel
BuildRequires:  gtkmm2-devel
License:        GPL-3.0+
Group:          Hardware/TV
Version:        1.3.6
Release:        1.0
Summary:        Me TV DVB application
Url:            https://launchpad.net/me-tv
Source:         http://launchpad.net/me-tv/1.3/%{version}/+download/me-tv-%{version}.tar.gz
Source1:        http://launchpad.net/me-tv/1.3/%{version}/+download/me-tv-%{version}.tar.gz.asc
Patch:          translation_de.patch
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
Recommends:     %{name}-lang
Recommends:     libxine2-codecs
Recommends:     libvlc
# needed for transponder files
Recommends:     dvb
Recommends:     w_scan
%gconf_schemas_prereq

%description
Me TV is a digital television (DVB) viewer for GNOME/GTK
Me TV was developed for the modern digital lounge room with
a PC for a media centre that is capable of normal PC tasks
(web surfing, word processing and watching TV). It is not
designed to be a full-blown media centre, such as MythTV,
but will integrate well with an existing GNOME desktop.

%lang_package

%prep
%setup -q
%patch -p1

Das Paket dvb habe ich nach Recommends: gesetzt, das braucht man nicht zwingend. Die Kanalliste lasse ich immer über w_scan erstellen.
Für die Audiowiedergabe soll wohl noch libvlc nötig sein.
Bei gnome-doc-utils-devel bin ich mir nicht sicher, ob das wirklich nötig ist.

So weit so gut, denke ich.
Danke!

[per RPM gelöst] tar.gz aus "make install" erzeugen

josef-wien

abgdf

Anonymous

Gast

abgdf

Anonymous

Gast

josef-wien

Anonymous

Gast

Anonymous

Gast

abgdf

Sauerland

josef-wien

Anonymous

Gast

josef-wien

Anonymous

Gast

abgdf

Anonymous

Gast

josef-wien

Anonymous

Gast

josef-wien

Anonymous

Gast