Paket gebaut - wo ist meine .changes?

[Natureshadow]

Hallöchen,

ich habe ein Debian-Paket für mein Pidgin Last.fm Plugin gebaut. Es kann problemlos installiert werden und ist "lintian-clean".

Nun möchte ich es zu mentors.debian.net hochladen - dafür brauche ich aber eine Datei mit der Endung .changes. Da es bei meinem Paket nichts zu kompilieren gibt, ist es kein Source-Package.

Hier die entsprechenden Dateien:

http://pub.naturalnet.de/pidgin-lastfm_0.3_all.deb - das fertige Paket
http://pub.naturalnet.de/pidgin-lastfm_0.3_all.tar.bz2 - der Baum aus dem ich es mit dpkg -b generiert habe

Kann mir jemand weiterhelfen?

Grüße,
Nik

[jhr-online]

Ich vermute mal...
Du hast ein natives Debian-Paket gebaut. Das willst du nicht. :)
"Debian native packages" sind Pakete, die Programme enthalten, die es nur für und wegen Debian gibt (dpkg zum Beispiel). Nahezu jedes andere Paket ist eins aus "fremden" Quellen, weil es auch außerhalb von Debian Sinn macht. Zwischen dem Debian-Paket und dem Original-Paket (i.d.R. ein tar.gz) gibt es dann Unterschiede (mindestens das "debian"-Verzeichnis) und die stehen im .changes-File.

Um ein nicht-natives Paket zu bauen, erstellt man ein Verzeichnis "paketname-upstreamversion" (Bsp.: pidgin-lastfm-1.1) und packt da den Quellcode rein (inkl. "debian"-Verzeichnis). Eine Verzeichnisebene höher muss dann der gepackte Originalcode liegen in der Form paketname_version.orig.tar.gz (pidgin-lastfm_1.1.orig.tar.gz). Wenn du dann das Paket baust, wird es automatisch als nicht-nativ erkannt und los geht's.

Zu guter Letzt noch: ich hoffe, du baust in einer sicheren sid-chroot; sonst hat das ganze nämlich wenig Sinn. :)

jhr

[jhr-online]

Noch was zum Paket:
* Leere postinst, prerm machen keinen Sinn. Einfach weg lassen.
* Im copyright file fehlt die Angabe darüber, wer das Copyright des Upstream Paketes hat (also, wer das Plugin geschrieben hat).

jhr

[Natureshadow]

Um ein nicht-natives Paket zu bauen, erstellt man ein Verzeichnis "paketname-upstreamversion" (Bsp.: pidgin-lastfm-1.1) und packt da den Quellcode rein (inkl. "debian"-Verzeichnis). Eine Verzeichnisebene höher muss dann der gepackte Originalcode liegen in der Form paketname_version.orig.tar.gz (pidgin-lastfm_1.1.orig.tar.gz). Wenn du dann das Paket baust, wird es automatisch als nicht-nativ erkannt und los geht's.

Nein nein ... Das geht so ja eben nicht. Dafür müsste mein Quellcode ja ein Makefile haben. Da es aber nur ein einzelnes Perl-Skript ist, das in /usr/lib/pidgin kopiert werden soll ...

Zu guter Letzt noch: ich hoffe, du baust in einer sicheren sid-chroot; sonst hat das ganze nämlich wenig Sinn.

Da ich ja nichts kompiliere - kein chroot.

Noch was zum Paket:
* Leere postinst, prerm machen keinen Sinn. Einfach weg lassen.
* Im copyright file fehlt die Angabe darüber, wer das Copyright des Upstream Paketes hat (also, wer das Plugin geschrieben hat).

Wenn ich postinst und prerm weglassen, meckert lintian. Das Copyright muss ich noch hinzufügen. Auch wenn der Copyrightinhaber ebenfalls ich bin

-nik

[Profbunny]

Code: Alles auswählen

Nein nein ... Das geht so ja eben nicht. Dafür müsste mein Quellcode ja ein Makefile haben. Da es aber nur ein einzelnes Perl-Skript ist, das in /usr/lib/pidgin kopiert werden soll ...

doch
bau dein paket im pbuilder sid

such mal im listenarchiv von mentors, das wurde vor gar nicht langer zeit durchgespielt wie du das handhaben musst.

Code: Alles auswählen

profbunny@sysiphus:/tmp/package$ lintian -i pidgin-lastfm_0.3_all.deb 
W: pidgin-lastfm: maintainer-script-empty prerm
N:
N:   The maintainer script doesn't seem to contain any code other than
N:   comments and boilerplate (set -e, exit statements, and the case
N:   statement to parse options). While this is harmless in most cases, it
N:   is probably not what you wanted, may mean the package will leave
N:   unnecessary files behind until purged, and may even lead to problems
N:   in rare situations where dpkg would fail if no maintainer script was
N:   present.
N:   
N:   If the package currently doesn't need to do anything in this
N:   maintainer script, it shouldn't be included in the package.
N:
W: pidgin-lastfm: maintainer-script-empty postinst
W: pidgin-lastfm: copyright-without-copyright-notice
N:
N:   The copyright file for this package does not appear to contain a
N:   copyright notice. You should copy the copyright notice from the
N:   upstream source (or add one of your own for a native package). A
N:   copyright notice must consist of Copyright, Copr., or the Unicode
N:   symbol of C in a circle followed by the years and the copyright
N:   holder. A copyright notice is not required for a work to be
N:   copyrighted, but Debian requires the copyright file include the
N:   authors and years of copyright, and including a valid copyright notice
N:   is the best way to do that.
N:   
N:   If the package is in the public domain rather than copyrighted, be
N:   sure to mention "public domain" in the copyright file. Please be aware
N:   that this is very rare and not the same as a DFSG-free license. True
N:   public domain software is generally limited to such special cases as a
N:   work product of a United States government agency.
N:   
N:   Refer to http://ftp-master.debian.org/REJECT-FAQ.html for details.
N:
W: pidgin-lastfm: description-synopsis-might-not-be-phrased-properly
N:
N:   The synopsis (first line in the package "Description:" field, the
N:   short description) ends with a full stop "." character. This is not
N:   necessary, as the synopsis doesn't need to be a full sentence. It is
N:   recommended that a descriptive phrase is used instead.
N:   
N:   Note also that the synopsis is not part of the rest of the
N:   "Description:" field.
N:   
N:   Refer to Policy Manual, section 3.4.1 for details.
N:
profbunny@sysiphus:/tmp/package$ 

soviel zu deinem linitan, es ist zu alt würde ich tippen, wie soll ich den erstellungsprozes nachvollziehen können?

[jhr-online]

Nein nein ... Das geht so ja eben nicht.

Doch doch, das geht so.

Dafür müsste mein Quellcode ja ein Makefile haben. Da es aber nur ein einzelnes Perl-Skript ist, das in /usr/lib/pidgin kopiert werden soll ...

Und du glaubst, dass all die Pakete, die nicht-kompilierte Sprachen enthalten (also alle php-Anwendungen zum Beispiel) debian-native Pakete sind? Na, das würde ich noch mal überdenken. :-P

Da ich ja nichts kompiliere - kein chroot.

Du brauchst das chroot nicht nur, wenn Sprachen kompiliert werden. Auch Abhängigkeiten müssen geprüft werden etc. Du musst ein Paket *immer* in einem sid-System bauen, weil evtl. Pakete in Etch nicht mehr in sid sind oder andersrum. Es gibt genügend Gründe für chroot. Einen noch: Wenn du im debian/rules einen fiesen Fehler reingebaut hast, kann das chroot dich retten, weil du dein System nicht versauen kannst. :)

Wenn ich postinst und prerm weglassen, meckert lintian. Das Copyright muss ich noch hinzufügen. Auch wenn der Copyrightinhaber ebenfalls ich bin :)

Dann schnapp dir ein aktuelleres lintian, aber das wurde ja auch schon gepostet und ja, selbst dein eigener Name ist wichtig.

jhr

PS: Mein Tipp: pbuilder + cowdancer

[KBDCALLS]

Du brauchst das chroot nicht nur, wenn Sprachen kompiliert werden. Auch Abhängigkeiten müssen geprüft werden etc. Du musst ein Paket *immer* in einem sid-System bauen, weil evtl. Pakete in Etch nicht mehr in sid sind oder andersrum. Es gibt genügend Gründe für chroot. Einen noch: Wenn du im debian/rules einen fiesen Fehler reingebaut hast, kann das chroot dich retten, weil du dein System nicht versauen kannst.


jhr

Dann mußte wir mal folgendes erklären.

"pbuilder update" updates the image to the current state of testing/unstable/whatever

Nach deiner Definition würde es ja gar keinen Sinn machen was anderes als ein Sid Changeroot zu bauen. Das Binary welches auch Sid kompiliert würde möchte ich sehen, und dann anschließend auf Etch oder Sarge funktioniert.

[jhr-online]

Ach je, schrei doch nicht gleich so... :-D

Wir haben es hier mit einem Paketbauanfänger zu tun. Er will sein Paket euf mentors hochladen, also soll es wohl neu in den Debian pool. Unter diesen Umständen macht nur das Bauen unter sid Sinn. Wenn das alles gelaufen ist und etwas Erfahrung gesammelt wurde etc., dann kann man darüber nachdenken zu backporten oder so... aber bis dahin behalte ich Recht. :)
Du hast natürlich der Vollständigkeit halber Recht; ich wollte es nur nicht noch komplizierter machen als es eh schon ist. :)

jhr

[Natureshadow]

Ach je, schrei doch nicht gleich so...

Wir haben es hier mit einem Paketbauanfänger zu tun. Er will sein Paket euf mentors hochladen, also soll es wohl neu in den Debian pool. Unter diesen Umständen macht nur das Bauen unter sid Sinn. Wenn das alles gelaufen ist und etwas Erfahrung gesammelt wurde etc., dann kann man darüber nachdenken zu backporten oder so... aber bis dahin behalte ich Recht.
Du hast natürlich der Vollständigkeit halber Recht; ich wollte es nur nicht noch komplizierter machen als es eh schon ist.

jhr

So ist's gut