git-buildpackage: Grundsätzliche Fragen

Zitat von goldbär

Ich vermute, dass alles unter /etc als Konfiguration angesehen wird. Aber was ist dann mit den Dateien in /var/lib/vdr/?

In /var/lib/vdr gibt es IMHO keine Conffiles.

Gerald

Zitat von goldbär

Wo liegt denn z.B. die channels.conf? Die wird ja normalerweise vom User erstmalig erstellt und dann vom vdr geändert.

Das ist kein Konfig-File, weil es vom User vdr geändert wird. Konfig-Files werden von root geändert. Die channels.conf ist eine Datenbank.

Gerald

Hallo,

ich wollte mal das aktuelle nopacity testen.
Also dachte ich, selbst ist der Mann und bin ähnlich wie von Mini73 skizziert vorgegangen:

git config --global user.name "Your Name"
git config --global user.email you@example.com


mkdir vdr-plugin-skinnopacity
cd vdr-plugin-skinnopacity
git init
git remote add upstream git://projects.vdr-developer.org/skin-nopacity.git
git fetch upstream
git checkout --no-track -b master upstream/master
# debian und .pc von Source kopiert, die mit apt-get source von yavdr/testing geholt wurde
# debian/changelog ändern mit:
dch -i -u medium
# öffnet editor
git add debian
git commit  -m "add debian directory"
# damit git-buildpackage klappt, musste ich einen branch mit dem richtigen Namen anlegen
git branch upstream/0.1.1_git-201304161330
git-buildpackage -tc -uc -us
cd ..
dpkg -i vdr-plugin-skinnopacity_0.1.1~git-201304161330-0yavdr0~precise_amd64.deb

Hat so funktioniert.
Wäre aber trotzdem an Kommentaren und weiteren Tipps interessiert.

Tschüß Frank

Moin!

".pc" gehört nicht ins git. Das sind nur temporäre Dateien von quilt oder so.

git-buildpackage funktioniert am besten, wenn upstream für jeden Release eine Versionsnummer als Tag hinterlegt wird. Deshalb brauchtest du einen neue Branch, weil git-buildpackage nicht zu der Version gefunden hat.
Ansonsten musst du vorher per "dch -i -u medium" einen passenden changelog-Eintrag mit der neuen Versionsnummer einpflegen (alles vor dem letzten Minus ist die upstream-Version).
Im Zweifelsfall den entsprechenden Commit selbst taggen.

Lars.

Hallo,

Zitat von mini73

git-buildpackage funktioniert am besten, wenn upstream für jeden Release eine Versionsnummer als Tag hinterlegt wird.

Ja, ich glaube in nopacity sind keine Tags.

Zitat von mini73

Ansonsten musst du vorher per "dch -i -u medium" einen passenden changelog-Eintrag mit der neuen Versionsnummer einpflegen

Wie wäre es mit git-dch statt dch?
Muss nur mal rausfinden, welche Parameter da schlau sind.

Zitat von mini73

(alles vor dem letzten Minus ist die upstream-Version)

Was meinst du damit?

Zitat von mini73

Im Zweifelsfall den entsprechenden Commit selbst taggen.

Was hatte ich da im obenigen Beispiel machen müssen?

Tschüß Frank

Moin!

Zitat von FrankJepsen

Wie wäre es mit git-dch statt dch?
Muss nur mal rausfinden, welche Parameter da schlau sind.

Hatte ich auch mal versucht, aber mit dch komme ich besser zurecht...
Hängt halt immer stark vom upstream-git ab, ob die git/gbp-Tools vernünftig arbeiten.

Zitat von FrankJepsen

0.1.1~git-201304161330-0yavdr0~precise

So steht's z.B. im changelog. dpkg interpretiert alles vor dem letzten Minuszeichen als die Upstream-Version, hier also 0.1.1~git-201304161330. Deshalb wird nach diesem Tag gesucht.

Zitat von FrankJepsen

Was hatte ich da im obenigen Beispiel machen müssen?

Wenn du vor dem buildpackage einen neuen changelog-Eintrag mit der passenden Version erstellst (z.B. Datum passend setzen oder wie auch immer) und du dann den entsprechenden Commit mit "git tag <Version> <CommitID>" kennzeichnest, sollte er automatisch eigentlich ein orig-Tar erstellen und bauen (vermute ich). Hab's jetzt nicht explizit ausprobiert.

Ich nehme mittlerweile meistens die "Abkürzung":

• mit "apt-get source" das aktuelle Paket holen
• mit "git clone" den aktuellen Upstream-Stand holen
• mit "git archive" ein orig-Tar erstellen
• debian-Verzeichnis rüberkopieren
• changelog anpassen, Patches (falls vorhanden) modifizieren
• pdebuild, um zu gucken, ob's noch baut
• debuild und dput, um es ins PPA zu laden

Lars.