staging.inyokaproject.org

Hallo Artikel teilweise fehlerhaft, in 18.04.

Habe die ganze WO Hibiscus Pakete gebaut, mir die Infos zusammen getragen. Wenn ich das hier nutze bekomme ich vom Server "abgelehnt"

Sollte mal eine Hinweis oben rein. Ich wollte mir das aber nicht anmaßen.

Artikel könnte wesentlich, vereinfacht werden? Datei Beschreibung auslagern?

Gruß

Hallo,

was stimmt den nicht? AFAIK sollte sich da nichts geändert haben.

Gruß, noisefloor

Hallo

Z.B. dh_make -f ../hello-2.7.tar.gz

Baue gerade aktuell neue Pakete, habe hier die Vorgehensweise für mich in einer .txt gespeichert.

Gruß

Win32netsky schrieb:

Artikel teilweise fehlerhaft, in 18.04.

Konkret?

Wenn ich das hier nutze bekomme ich vom Server "abgelehnt"

Da kommen glatt noch mehr Infos von Launchpad...

Auch können diese Artikel nicht jeden Fall abdecken, da es dafür schlichtweg zu viele Möglichkeiten gibt.

Artikel könnte wesentlich, vereinfacht werden?

Konkret? Eigentlich™ ist der nicht mal ausreichend, um auf alles einzugehen.

Hallo

Ist ja nur meine Vorstellung, den Artikel so zu gestalten das er nur das minimalste an Standard nutzt. Er kann natürlich auch so bleiben, oben steht ja das für alle Versionen Gültig.

Genaue Informationen auslagern?

Das Beispiel:

Mein Beispiel dh_make -f ../hello-2.7.tar.gz

es funktioniert, aber bei mir wird z.B. im Standard eine .xz Datei erstellt.

Nach meiner Meinung ist dies dann fehlerhaft, oder ?

Ich habe z.B. in der Auswahl, .zip, .tar.xz, .7z

Ich habe meine Pakete fertig, mir alle Informationen zusammengetragen und für mich gespeichert.

Gruß

Hallo,

ich würde vorschlagen, beim Hauptartikel die getestet: general-Markierung zu entfernen, aufgrund der Installation von Abhängigkeiten. Beispielsweise musste ich für lintian erst kürzlich eine nicht (mehr) existente Option entfernen.

Hallo,

ich habe nun mal versucht, die Anleitung abzuarbeiten, siehe: probleme-beim-paketbau-nach-wiki-anleitung

Dabei stieß ich auf Probleme, Unklarheiten und letztlich die Fehlfunktion des Bauens des Binär-Pakets. Vielleicht lässt sich der Artikel ja noch verbessern, um die Unklarheiten zu beseitigen.

UlfZibis schrieb:

Also im Grunde dasselbe, was ich schon unter Copyright: eingetragen habe. Bei letzterem wundere ich mich, dass ich da dann nur mich eintrage, und nicht auch die Ersteller der Originalversion. […]

Nee, damit ist der Ersteller der Originalversion gemeint. Upstream ist Paketierer-Slang für den Ursprung eines Programms.

[…] Ich meine, dass aus dem Codeblock nicht klar wird, was da zum "ersten" und was zum "zweiten" Format gehört. Irritierend ist dann zusätzlich, dass im Beispiel darunter die Reihenfolge der Parameter vertauscht ist.

Ich habe einen kleinen Hinweis hinzugefügt; die erste Zeile gibt die Version des gesamten uscan-Vokabulars an und gehört nicht zu den gezeigten Formaten.

Siehe die uscan-Manpage; Version 4 ist empfohlen.

Merkwürdig, dass das aktuelle debmake dann Version 3 vorgibt.

Die hängen wohl hinterher. Jedenfalls gibt lintian aus:

I: hello source: older-debian-watch-file-standard 3 [debian/watch]
N: 
N:   The version= line in the debian/watch file in this package declares an
N:   older version. Please upgrade when you have a chance.
N: 
N:   Please refer to the uscan(1) manual page for details.

An der, die vorher mit uquilt add zum Patch hinzugefügt wurde. Also in diesem Fall doc/Makefile.in.

Hm. ich habe an der Datei aber nichts geändert. Ich wüsste auch nicht, was ich an der sinnvolles ändern könnte/sollte. Heißt das, dass ich den ganzen Patch-Aufwand auslassen kann, wenn ich da nix geändert habe bzw. ändern will?

Ich bin doof und habe kurzerhand den Patch entfernt, der angewendet werden soll. Jetzt ist er wieder drin.

Und heißt das, dass ich den ganzen Aufwand ggf. für jede Datei eines Projekts, an der ich was geändert habe, treiben muss?

Nicht für jede Datei, sondern für jeden behobenen Fehler. Der wird dann im Changelog vermerkt.

Naja, deine .changes-Datei hat ja auch eine angepasste Version (inkl. Ubuntu-Revision). Du musst lintian schon eine Datei übergeben, die existiert.

Hmm, ich finde da nirgendwo eine .changes-Datei. Welche ist da gemeint.

Die .changes-Datei enthält die Metadaten des Binärpakets und wurde beim Bau des Quellpaketes erstellt (hat ja dein ls-Aufruf gezeigt). Eigentlich muss lintian in diesem Fall gar nicht manuell aufgerufen werden, das übernimmt ja schon debuild; es sollte nur eine Erläuterung sein. Habe ich vermerkt.

Der nun folgende Bau des Binär-Pakets führt leider jedenfalls zu Fehlern: […]

Kann ich mir momentan nicht erklären.

Kriegst Du den Fehler denn nicht, wenn Du das so machst, wie im Artikel beschrieben bzw. wie ich es probiert habe?

Ich gebe zu, das beim letzten Test überhaupt nicht mit dieser alten Version durchgespielt zu haben, ich Schlendrian. Diesen Patch habe ich ausbaldowert:

1
2
3
4
5
6
7
8
9

--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -20,5 +20,4 @@
 EXTRA_DIST = $(TESTS)
 
 TESTS_ENVIRONMENT = top_srcdir=$(top_srcdir) PATH=.:../src:$$PATH \
-		    HELLO=`echo hello|sed '$(transform)'` \
-		    $(SHELL)
+		    HELLO=`echo hello|sed '$(transform)'`

Müsste eigentlich funktionieren. Ich muss das glaube ich dringend auf die neueste Version von GNU hello anpassen; die ist von 2025.

Sehr schön, danke Dir.

Kann man das so verstehen, dass in dem GNU-Hello-Paket absichtlich Fehler drin sind, damit man damit den Paketbau mit Patch üben kann?

Wenn nicht, fände ich das durchaus interessant, diese alte Version im Artikel zu belassen, eben als Übungsanleitung für eine Korrektur. Wenn ich es richtig verstehe, wird ja dann durch den Watch-Mechanismus beim nächsten Apt-Update die selbst erstellte Version von der aktuellen überschrieben und man könnte dann auch das testen / beobachten.

Das sollte dann aber auch explizit so herausgestellt werden.

Der Befehl uscan erzeugt folgendes:

:~/Projects/gnu-hello_3/hello-2.7$ uscan
Newest version of hello on remote site is 2.12.2, local version is 2.7
 => Newer package available from:
        => http://ftp.gnu.org/gnu/hello/hello-2.12.2.tar.gz
uscan warn: Possible OpenPGP signature found at:
   http://ftp.gnu.org/gnu/hello/hello-2.12.2.tar.gz.sig
 * Add opts=pgpsigurlmangle=s/$/.sig/ or opts=pgpmode=auto to debian/watch
 * Add debian/upstream/signing-key.asc.
 See uscan(1) for more details
Successfully symlinked ../hello-2.12.2.tar.gz to ../hello_2.12.2.orig.tar.gz.
uupdate: debian/source/format is "3.0 (quilt)".
uupdate: Auto-generating hello_2.7-1~0ubuntu1.debian.tar.xz
uupdate: -> Copy to      hello_2.12.2-0ubuntu1.debian.tar.xz

Ich denke mal, das sollte man hier jetzt besser nicht ausführen, weil man ja mit den alten Sourcen inkl. Patch erstmal weiterarbeiten will, oder ???

Zum Abschnitt Patchen:
Wäre es da nicht sinnvoll, wenn man da in der Anleitung einen passenden patch ... Befehl unter Verwendung des gezeigten Patches angeben würde, statt dass man die Änderung an doc/Makefile.in per Hand vornehmen muss?
Dann steht da, dass mit dem Befehl uquilt push -a die Datei doc/Makefile.in wieder in den Ursprungszustand versetzt wird. Bei mir ist das nicht der Fall, die manuelle Änderung bleibt.

Nun beim Abschnitt Paketbau angekommen funktioniert folgendes immer noch nicht:

:~/Projects/gnu-hello_3/hello-2.7$ lintian -EvI --pedantic --show-overrides --color=auto hello_2.7-1~0ubuntu1_amd64.changes
hello_2.7-1~0ubuntu1_amd64.changes is not a readable file

Es gibt in dem Stadium keine Datei *.changes.
Außerdem müsste es wohl

hello_2.7-1~0ubuntu1_source.changes

heißen.

Sorry for the inconvenience, ich hätte das alles noch ein bisschen ausführlicher behandeln sollen. Danke, dass Du Dich als fleißiger Tester betätigst.

UlfZibis schrieb:

[...] Ich denke mal, das sollte man hier jetzt besser nicht ausführen, weil man ja mit den alten Sourcen inkl. Patch erstmal weiterarbeiten will, oder ???

Also, uscan macht Folgendes:

• es lädt den Tarball der neuen Version in das Elternverzeichnis (gnu-hello) herunter

• Es legt den Tarball .orig.tar.gz als Symlink zum Originalen an

• Der Tarball wird entpackt, und in das Verzeichnis wird der alte Ordner debian kopiert

• Neupaketierung erfolgt durch manuelle Bearbeitung der Kontrolldateien unter debian bzw. etwaiges Patchen

Also wird die alte Paketierung nicht in Mitleidenschaft gezogen. Schreibe ich dazu.

Zum Abschnitt Patchen:
Wäre es da nicht sinnvoll, wenn man da in der Anleitung einen passenden patch ... Befehl unter Verwendung des gezeigten Patches angeben würde, statt dass man die Änderung an doc/Makefile.in per Hand vornehmen muss?

Joa,gute Idee; lässt sich machen.

Dann steht da, dass mit dem Befehl uquilt push -a die Datei doc/Makefile.in wieder in den Ursprungszustand versetzt wird. Bei mir ist das nicht der Fall, die manuelle Änderung bleibt.

Stimmt, der Satz ist falsch. push soll ja gerade zu Testzwecken den Patch anwenden. pop versetzt sie in den Ausgangszustand zurück.

[...] Es gibt in dem Stadium keine Datei *.changes.

Das ist richtig, der Befehl soll auch gar nicht ausgeführt werden. Ich hatte ja einen Satz hinzugefügt, dass das über debuild erfolgt. Der Abschnitt sollte eine Erläuterung zu lintian sein, bevor es aufgerufen wird. Vielleicht sollte er trotzdem einfach nach den Paketbau verschoben werden?

Außerdem müsste es wohl

hello_2.7-1~0ubuntu1_source.changes

heißen.

Das ist die Metadaten-Datei nach dem Bau des Quellpaketes; wenn man das Binärpaket baut, heißt sie anders. Möglicherweise ist der Platzhalter PAKET_VERSION.changes sinnvoll. Funktioniert für Dich jetzt der Bau des Binärpaketes?

UlfZibis schrieb:

[...] Kann man das so verstehen, dass in dem GNU-Hello-Paket absichtlich Fehler drin sind, damit man damit den Paketbau mit Patch üben kann?

Das glaube ich kaum, zumindest wenn man die Bescheibung betrachtet:

The primary purpose of GNU Hello is to demonstrate how to write other programs that do these things; it serves as a model for GNU coding standards and GNU maintainer practices.

Wenn nicht, fände ich das durchaus interessant, diese alte Version im Artikel zu belassen, eben als Übungsanleitung für eine Korrektur. […] Das sollte dann aber auch explizit so herausgestellt werden.

Auch eine Idee, wenn Du das Anwenden von zwei Patches nicht als zu abschreckend empfindest.

karzer schrieb:

Funktioniert für Dich jetzt der Bau des Binärpaketes?

Nein, leider nicht. ich hatte aber auch nur den Patch im Artikel angewandt, nicht den aus 9476413. (Warum 2 einzelne Patches, statt beide Änderungen in einem?)

Auch eine Idee, wenn Du das Anwenden von zwei Patches nicht als zu abschreckend empfindest.

In dem Artikel geht es ja darum, wie man exemplarisch ein Paket baut. Dazu gäbe es 2 Anlässe, erstens eigene Sourcen, oder zweitens Fehlendes oder Kaputtes in vorhandenen Sourcen.

Letzterer Anlass wurde hier exemplarisch gewählt. Dafür muss an irgendeiner Stelle der Code oder Bau-Mechanismus geändert werden. Dafür gibt es mindestens 2 Methoden:

1. Änderung manuell vornehmen

2. Nutzung mehr oder weniger raffinierter und aufwändiger Patch-, quilt- und uscan-Methoden.

Ich würde der Einfachheit und Übersichtlichkeit wegen erst mal ersteres vorschlagen, also "man tausche Zeilen abc mit Inhalt "..." in Datei xyz mit "..." aus.
Alle raffinierteren Methoden und Extras dann erst weiter unten aufführen, und da auch erst mal nur unter Verwendung des patch...-Befehls, im nächsten Abschnitt auch per quilt und uscan. Und den Watch-Mechanismus erst ganz am Schluss einbringen.

Der Nutzen wäre ein möglichst frühes erstes Erfolgserlebnis.

PS: Ich fände es jetzt auch nicht verkehrt, die Beiträge ab ca. 9476413 an den Diskussionsfaden des Artikels anzuhängen.

Jetzt, inklusive dem 2. Patch, funktioniert's. Folgendes habe ich ausgeführt:

$ tar -xvzf hello-2.7.tar.gz
$ cd hello-2.7/
$ export DEBFULLNAME="Ulf Zibis"
$ export DEBEMAIL="Ulf.Zibis@CoSoCo.de"
$ debmake -x1
$ cd debian/
$ rm -r README.Debian tests salsa-ci.yml
$ dch --release
$ cd ..
$ uquilt new 01-no-usr-share-info-dir-gz
$ uquilt add doc/Makefile.in
$ uquilt add tests/Makefile.am
$ uquilt refresh
$ uquilt push -a
$ debuild -S -us -uc --lintian-opts -EvI --pedantic --show-overrides --color=auto
$ debuild -us -uc --lintian-opts -EvI --pedantic --show-overrides --color=auto
$ sudo apt install ../hello_2.7-1~0ubuntu1_amd64.deb

Merkwürdig finde ich, dass jetzt nicht die neuere Version aus den Ubuntu-Quellen als Installationskanditat genommen wird. Durch den Watch-Mechanismus sollte das doch eigentlich so sein.

$ apt policy hello
hello:
  Installiert:           1:2.7-1~0ubuntu1
  Installationskandidat: 1:2.7-1~0ubuntu1
  Versionstabelle:
 *** 1:2.7-1~0ubuntu1 100
        100 /var/lib/dpkg/status
     2.10-3build1 500
        500 http://de.archive.ubuntu.com/ubuntu noble/main amd64 Packages

UlfZibis schrieb:

Jetzt, inklusive dem 2. Patch, funktioniert's. Folgendes habe ich ausgeführt: […]

Endlich, es funktioniert etwas! Ich habe den Artikel eben in die Baustelle verschoben, Du kannst gerne schon Änderungen vornehmen.

Merkwürdig finde ich, dass jetzt nicht die neuere Version aus den Ubuntu-Quellen als Installationskanditat genommen wird.

Der Grund dafür ist bereits im Artikel vermerkt:

Für das Beispiel wird nun die Version des Paketes von 2.7-1 zu 1:2.7-1~0ubuntu1 geändert. Die Epoch-Nummer wird gesetzt, da das Paket hello bereits in den Ubuntuquellen vorhanden ist und je nach Ubuntuversion schon in neuerer Version vorliegt, das selbsterstellte Paket aber installiert bleiben soll.

Durch den Watch-Mechanismus sollte das doch eigentlich so sein. […]

Die Funktionsweise dieses Mechanismus hatte ich ja bereits in 9476472 erläutert; der ist nur für Paketierer sinnvoll, die ihr eigenes Paket auf eine neue Version anpassen wollen und hat mit apt nichts zu tun.

UlfZibis schrieb:

[…] (Warum 2 einzelne Patches, statt beide Änderungen in einem?) […]

Weil ein Patch idealerweise auch genau einen Fehler beheben sollte; so kann man die Patches besser verwalten. Was wäre z. B., wenn das Problem in der nächsten Version in einem der beiden betroffenen Makefiles behoben wäre, das andere aber nicht? Dann müsste man einen neuen Patch erstellen, andernfalls könnte man den alten unkompliziert löschen. Außerdem erschließt sich so der Sinn eines jeden Patches besser (Du hast die verschiedenen Änderungen in einem Patch zusammengefasst, der deskriptiv 01-no-usr-share-info-dir-gz heißt). Siehe auch Atomic_commit dazu.