VDR & DVB Packaging

Persönlich wäre ich auch dafür, dass reine Changelog-/Versions-Änderungen immer eine NMU-Versionsnummer bekommen, also z.B.: 1.5.0-1yavdr1.1
Richtig, das wäre automatisch bei jeder Übernahme eines Paketes von dir nötig, weil wir ja im Changelog auf Lucid ändern und unsere Email-Adresse angeben müssen, damit wir das Signieren können.

sehr gute idee !

nicht ganz klar ist mir die benennung eines debian original + "nur" rebuild in unserem repo ?
1+yavdr1.1 ?

Wir sollten uns aber auch gleich eine Nomenklatur überlegen, mit der wir deutlich machen können, dass die Pakete zwar eine gemeinsame Basis, aber trotzdem Abweichungen haben, für den Falls dass wir uns mal nicht einigen konnten welche Patches wie einfließen sollen.

hoplo wrote:

sehr gute idee !

nicht ganz klar ist mir die benennung eines debian original + "nur" rebuild in unserem repo ?
1+yavdr1.1 ?

es ist nie nur rebuild, es ist immer eine Änderung im Changelog, oder was meinst du?

Ich glaube ich weiß was du meinst. Die Schreibweise für das debian orginal Paket können wir überhaupt nicht benutzen, wir können es aus technischen Gründen nicht 1 zu 1 übernehmen.

naja
angenommen toibi hat ein paket im repo wie jetzt
femon
bei uns 1.7.7 (warum auch immer) bei tob 1.7.8

jetzt hol ich mir das paket von tobi :
dget -u http://e-tobi.net/vdr-experimental/pool-squeeze/source/vdr-multipatch/vdr-plugin-femon_1.7.8-1.dsc

bastel mir einen neuen changelog eintrag mit dch

jetzt würde der so aussehen ?:

vdr-plugin-femon (1.7.8-1+0yavdr1.1) lucid; urgency=low

  * rebuild for yavdr

 -- Holger Schvestka <hotzenplotz5@gmx.de>  Mon, 08 Nov 2010 16:27:09 +0100

das 1.1 bezieht sich halt auf die "reine changelog änderung"

Ist es wirklich immer nötig, die Version/Changelog zu ändern? Ubuntu macht das auch nicht. Aber ich schätze wenn yaVDR öfters gegen eine geänderte vdr- oder libc-ABI compiliert kommt man um die Rebuild's mit neuer Version nicht drum herum.

A) Original: <base-version>
B) Ubuntu-Version mit Ubuntu-Änderungen: <base-version>ubuntu1
C) yaVDR nur Changelog-Änderung: <base-version>+yavdr0.1, <base-version>+yavdr0.2, ...
D) yaVDR mit anderen Änderungen: <base-version>+yavdr1, <base-version>+yavdr2, ...
E) yaVDR mit anderen Änderungen + Changelog-Only-Änderungen: <base-version>+yavdr2.1, ...

So könnte ich mir das vorstellen. Wichtig wäre, dass folgende Bedingungen zutreffen:

• A <= B
• A < C
• D > C
• E > D
• (dch -i von A) > (B, C, D, E)

etobi wrote:

Ist es wirklich immer nötig, die Version/Changelog zu ändern? Ubuntu macht das auch nicht.

Es ist nicht nötig die Version zu ändern, aber das Changelog und du hast selber vorgeschlagen dann NMU-Versionsnummer zu nehmen.

es muss ein neuer Eintrag rein wie dieser

dvb-driver-sundtek (20101105-1yavdr2) lucid; urgency=low

  * wrong version in makefile

 -- Gerald Dachs <gda@dachsweb.de>  Sat, 06 Nov 2010 13:30:28 +0100

etobi wrote:

Ubuntu macht das auch nicht.

Das ist nur in einem bestimmten Fall möglich: Der Ubuntu-Package-Maintainer ist auch gleichzeitig der Debian-Package-Maintainer.

Verstehe schon. Und auf jeden Fall immer ne neue Version, sonst werden die changelog-Diff's unlesbar.

Bei Ubuntu werden aber auch Pakete ohne Versions-Änderung übernommen, wenn der Maintainer ein anderer ist.

z.B.:

http://archive.ubuntu.com/ubuntu/pool/universe/v/vdr-plugin-sudoku/vdr-plugin-sudoku_0.3.5-2.dsc

Ubuntu-Maintainer ist aber ubuntu-motu@lists.ubuntu.com

Bei Ubuntu werden aber auch Pakete ohne Versions-Änderung übernommen, wenn der Maintainer ein anderer ist.

Dann verrate mir wie ich es signieren soll.

Gerald

etobi wrote:

Ubuntu-Maintainer ist aber ubuntu-motu@lists.ubuntu.com

Meine Vermutung ist, dass das keine echte Person ist und dass mehrere Ubuntu-Entwickler den Key für diese Adresse haben.

Gerald

Ich glaube, du bist mit den Keys generell auf dem falschen Dampfer. Unabhängig davon, welche e-mail-Adresse in changelog/control eingetragen ist, kannst du jedes Paket mit deinem Key signieren. So mache ich das z.B.:

debsign -kAEDAA642 vdr-plugin-imonlcd_0.0.5-0yavdr1_amd64.changes

So funktionieren ja z.B. auch sponsored Uploads.

Ändert allerdings nichts daran, dass Launchpad ggf. das "lucid" im changelog benötigt.

IMHO verlangt launchpad das Pakete mit der Signatur gesigned sind die auch im changelog steht, Ansonsten wird das Paket rejected. Aber das kann man ja mal ausprobieren demnächst.

"There are a couple of aspects of PPAs that work slightly differently to standard Ubuntu packages: versioning and dependencies. You should also ensure that the email address and GPG key you use with dput are the same as those associated with your Launchpad account."

Quelle: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage

Da ich einfach nicht glauben konnte, dass das so ist, hab ich jetzt selbst mal einen Launchpad-Account angelegt. Keine Ahnung, was ihr macht, aber ich kann problemlos Pakete hochladen OHNE das changelog zu ändern, obwohl dort eine fremde email-Adresse steht und obwohl die Distri noch auf "unstable" steht.

Der Beweis:

https://launchpad.net/~8-launchpad-e-tobi-net/+archive/ppa-e-tobi/+sourcepub/1360156/+listing-archive-extra

Ändert allerdings nichts daran, dass Launchpad ggf. das "lucid" im changelog benötigt.

braucht es ja trotzdem ?
oder gibt es da auch eine option ? wenn ja, wäre es ideal

Nein braucht es nicht, das kann beim upload überschrieben werden. z.B. so:

$ cat ~/.dput.cf 
[ppa-lucid]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~8-launchpad-e-tobi-net/ppa-e-tobi/ubuntu/lucid
login = anonymous
allow_unsigned_uploads = 0

Und dann halt:

dput ppa-lucid foo_0.1_source.changes